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ABSTRACT 


This  thesis  examines  the  feasibility  of  using  an  expert  system  approach  to 
design  an  intelligent  Weapon  Suggestion  System  (WSS)  to  assist  the 
Weapons  Department  Head  (WDH)  on  board  a  naval  warship  in  making 
accurate  and  efficient  decisions  in  critical  battle  situations. 

We  have  analyzed  the  constraints  of  a  WSS  and  the  performance  of  the 
on  board  weapons.  We  have  also  reviewed  the  related  material  previously 
published  and  discussed  the  implementation  environment  in  this  thesis.  The 
system  is  supported  by  the  Knowledge  Engineering  Environment  (KEE),  often 
referred  to  as  an  expert  system  shell  since  it  provides  a  comprehensive  set  of 
expert  system  building  tools  to  facilitate  the  development  of  expert  systems. 

The  WSS  receives  preprocessed  sensor  input,  determines  what  contacts 
are  present,  performs  target  analysis  and  correlation  based  upon  the  current 
tactical  situation,  and  suggests  the  most  effective  weapon(s)  to  deploy  against 
various  hostile  targets.  Simulation  results  have  shown  that  the  system  can 
provide  timely  decision  support  in  a  time-critical  combat  environment. 
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INTRODUCTION 


A.  THE  PROBLEM  STATEMENT 

At  present,  navies  around  the  world  are  being  challenged  by  the  changing 
face  of  modern  warfare.  With  the  development  of  missile  technology  in  1944, 
the  patterns  of  naval  operations  have  been  totally  transformed  in  the  post 
World  War  II  era.  Today,  almost  every  nation  around  the  world  that  aspires 
to  military  power  can  be  characterized  by  an  extraordinary  concentration  of 
resources  centered  on  weapons  development.  Weapons  that  are  more 
powerful,  faster,  and  more  accurate  are  successfully  implemented  one  after 
another.  Thus  we  can  imagine  that  the  warfare  of  the  future  will  be  a  rapid- 
fire  affair  and  that  the  type  of  warfare  will  become  more  complex  and 
technology  dependent. 

Naval  warships  confronting  hostile  contacts  can  choose  between  a  "Soft- 
kill"  or  a  "hard-kill."  "Soft-kill"  implies  employing  decoys  such  as  chaff, 
flares,  and  other  electronic  devices  to  interfere  with  and  "confuse"  hostile 
targets.  "Hard-kill"  is  to  employ  weapons  on  board  to  destroy  the  hostile 
targets.  Though  the  utilization  of  both  methods  is  vital  for  a  vessel  to 
counterattack,  in  this  thesis  we  concentrate  only  on  the  "hard-kill"  responses 
against  incoming  targets. 

As  a  general  rule,  any  naval  force  cruising  at  sea  must  always  be  prepared 
to  encounter  the  three  dimensional  threat  of  air,  surface,  and  subsurface 
attack.  However,  as  was  demonstrated  in  recent  naval  encounters,  such  as  the 
Falkland  Conflict,  USS  Stark  in  the  Persian  Gulf,  and  the  Israeli  destroyer 
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Eilat  which  was  sunk  during  an  encounter  with  the  Egyptian  Navy  in  1967,  it 
is  obvious  that  in  confined  waters  the  threat  from  the  air  attack  poses  the 
highest  damage  threat  potential.  Hence,  we  have  extended  this  assumption 
into  the  structure  of  our  paper  as  well  as  into  our  simulations. 

Drawing  further  upon  the  naval  engagements  in  the  post  World  War  H, 
it  can  be  decisively  illustrated  that  the  defensive  responses  of  the  vessel  under 
attack  must  be  expeditions  and  accurate  in  order  to  avoid  serious  damage 
and/or  sinking  (i.e.  British  destroyer  Sheffied  during  the  Falkland  Conflict  in 
1982  and  the  US  frigate  Stark  in  the  Persian  Gulf  in  1987). 

B.  OBJECTIVES 

The  purpose  and  intent  of  this  thesis  is  to  demonstrate  that  the  Weapon 
Suggestion  System  (WSS)  can  provide  the  Weaponry  Department  Head 
(WDH)  reliable  weapon  suggestion  instructions.  The  system  will  decrease  the 
reaction  time  to  suggest  weapons  against  targets  and  maximize  the  efficiency 
of  weapon  utilization  on  board.  We  have  designed  and  implemented  the 
Weapon  Suggestio’  System  using  Knowledge  Engineering  Environment 
(KEE).  The  reasons  for  using  an  expert  system  (WSS)  to  aid  decision-support 
process  are  as  follows: 

•  Within  the  scope  of  a  tactical  military  operation,  knowledge,  data  and 
the  decision-support  process  are  so  closely  related  as  to  be  essentially  one 
function. 

•  The  increased  speed  of  the  incoming  threats  have  reduced  the  time 
available  for  human  formulation  of  tactical  decisions. 

•  A  tactical  situation  is  always  fluid  and  volatile.  A  well  designed  expert 
system  can  maintain  the  maximum  efficiency  of  on  board  weapons 
within  fluid  strategic  parameters. 
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C  ORGANIZATION  OF  THE  THESIS 

The  above  discussion  illustrates  the  need  of  ’  i::ing  an  intelligent  expert 
system  to  help  the  decision-support  process.  Th2  process  in  our  design 
includes  data  acquisition,  analysis  and  a  suggestion  phase.  During  the 
acquisition  phase,  the  WSS  receives  target  data  from  various  sensors, 
information  netvkrorks,  or  human  interface,  and  stores  that  information  in  its 
dynamic  database.  In  the  analysis  phase,  the  WSS  scans  its  database  to 
identify,  classify  and  calculate  the  comparative  threat  and  class  of  the  target.  In 
the  suggestion  phase,  the  WSS  will  survey  the  weaponry  available  on  board 
and  suggest  the  optimum  weapons  engagement  against  hostile  targets. 

The  remainder  of  this  thesis  is  organized  as  follows:  Chapters  II  provides 
some  basic  background  about  Artificial  Intelligence  (AI),  expert  systems,  and 
general  military  applications.  In  Chapter  III  we  review  previous  research 
related  to  this  thesis  and  analyze  the  results.  Chapter  IV  describes  the 
functions  and  limitations  of  the  Weapon  Suggestion  System.  The  peripheral 
devices  of  WSS  are  also  discussed  in  this  chapter.  Chapter  V  presents  the 
software  architecture  knowledge  rules,  and  simulation  process  and  their 
results  in  detail.  Finally,  Chapter  VI  discusses  the  possibilities  of  future 
enhancement  to  the  performance  and  power  of  the  system. 
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n.  GENERAL  BACKGROUND 


A.  ARTIFiaAL  INTELLIGENCE  AND  EXPERT  SYSTEMS 

1.  Introduction 

Artificial  intelligence  (AI)  is  a  branch  of  computer  science  dedicateed 
to  the  study  of  computational  machinery  that  exhibits  intelligent  behavior. 
During  the  past  20  years,  AI  research  has  evolved  from  a  purely  academic 
activity  into  a  major  business  involving  both  government  and  commercial 
applications.  In  the  past  few  years,  there  has  been  an  explosive  growth  in  the 
number  of  AI  systems  oriented  toward  providing  users  with  systems  capable 
of  offering  advice  on  a  variety  of  problems  such  as  classification,  diagnosis, 
and  planning.  This  chapter  explores  AI  concepts,  technologies,  and  military 
applications. 

2.  Basics  of  Expert  Systems 

Of  the  various  types  of  AI  systems,  expert  systems  have  received  the 
most  public  exposure.  Expert  system  technology  is  widely  perceived  as  the  AI 
technology  with  the  most  potential  for  the  development  of  near-term 
applications.  Expert  systems  are  computer  programs  that  are  equipped  with 
expert  knowledge  to  help  users  solve  real-world  problems.  For  example,  an 
expert  system  called  MYCIN  provides  expert  advice  to  medical  doctors  on  the 
diagnosis  and  treatment  of  various  types  of  bacterial  infections.  It  is 
considered  an  "expert"  system  because  its  procedures  for  diagnosing  and 
recommending  treatment  are  modeled  after  judgmental  heuristics  employed 
by  human  experts.  Emulating  human  expert  behavior  is  often  considered  an 
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essential  characteristic  of  an  expert  system.  In  the  following  section,  a  basic 
introduction  to  expert  system  technology  is  provided. 
a.  Knowledge  Base  and  Inference  Engine 

Virtually  all  expert  systems  contain  three  basic  components:  a 
knowledge  base,  an  inference  engine,  and  a  user  interface.  In  the  knowledge 
base,  domain-specific  knowledge  is  expressed  as  a  set  of  condition-action  pairs 
referred  to  as  production  rules  that  specify  the  action  to  be  carried  out  if  the 
prerequisite  conditions  are  satisfied.  The  role  of  the  inference  engine  is  to 
control  the  order  of  rule  activation  and  to  update  the  belief  value  of  the 
hypotheses  based  upon  acquired  evidence.  A  user  interface  caters  to  a  smooth 
communication  between  the  user  and  the  system.  It  may  also  provide  the 
user  with  an  insight  into  the  problem-solving  process  carried  out  by  the 
inference  engine.  It  is  convenient  to  view  the  inference  engine  and  the 
interface  as  one  module,  usually  called  an  expert  system  shell,  or  shell.  Figure 
2-1  illustrates  the  basic  expert  system  architecture. 

The  advantages  of  separating  knowledge  base  from  inference 

engine  are: 

•  Knowledge  can  be  represented  in  a  uniform  fashion  (i.e.  If.. .then...  style). 

•  The  same  inference  engine  and  user  interface  can  be  applied  to  different 
problem  domains  (one  only  needs  to  add  new  knowledge). 

•  It  allows  modifications  of  one  part  without  creating  side  effects  in  other 
parts  of  the  code. 

•  System  builders  can  focus  directly  on  capturing  and  organizing  problem¬ 
solving  knowledge  rather  than  on  the  details  of  low  level 
implementations. 

•  It  allows  experimentation  with  alternative  control  regimes  for  the  same 
rule  base. 
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Figure  2-1.  A  Simplified  View  of  Expert  System  Architecture 

Most  expert  systems  deal  with  various  classes  of  inference 
problems,  where  the  expert  system  must  draw  conclusions  from  various 
evidence  or  data  inputs.  In  these  types  of  inference  problems,  the  set  of  rules 
(just  like  Figure  2-2)  in  rule-base  can  be  graphically  represented  in  the  form  of 
a  set  of  inference  networks.  As  illustrated  in  Figure  2-3,  an  inference  networks 
contains  top-level  hypotheses,  called  goal  hypotheses,  that  are  decomposed 
into  various  levels  of  subhypotheses.  The  subhypotheses,  in  turn,  are  further 
broken  down  into  specific  items  of  evidence  that  can  support  those 
hypotheses.  With  each  node  there  is  usually  an  associated  prior  degree  of 
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belief  and  a  rule  for  combining  subnode  belief  values  into  an  updated  degree 
of  belief  for  the  node. 

b.  Control  Strategies 

The  inference  engine  described  above  is  theoretically  sufficient 
for  processing  rule  hierarchies  of  any  size.  However,  as  the  number  of  rules 
in  a  rule  base  increases,  the  behavior  of  acquiring  all  available  evidence  or 
primitive  values  would  become  very  inefficient,  as  well  as  frustrating  to  a 
user  if  he  or  she  must  enter  all  the  data.  To  efficiently  manage  the  application 
of  domain  knowledge  to  specific  problems,  inference  engines  apply  a  control 
strategy  that  carefully  controls  the  order  of  rule  activation. 

IF :  The  exhaust  is  smoky,  and 
The  car  is  backfiring,  and 
There  is  a  lack  of  power, 

THEN  :  The  carburetor  fuel  mix  is  too  rich. 

IF :  There  is  a  lack  of  power,  and 

There  is  a  gray  deposit  on  the  spark  plugs,and 
The  engine  overheats, 

THEN  :  The  carburetor  fuel  mix  is  too  weak. 

IF :  The  carburetor  fuel  mix  is  too  rich,  or 
The  carburetor  fuel  mix  is  too  weak, 

THEN  :  The  carburetor  fuel  mix  needs  to  be  adjusted. 

Figwe  2-2.  Sample  Production  Rules 
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One  common  strategy  is  to  select  a  goal  hypothesis,  usually  a  top 
level  hypothesis  in  the  rule  hierarchy,  and  to  chain  down  the  hierarchy  one 
rule  at  a  time  to  identify  intermediate  and  primitive  clauses  that  impact  the 
selected  goal  hypothesis.  The  expert  system  then  gathers  data  about  evidence 
items  specifically  related  to  the  goal  hypothesis  of  interest.  This  approach  of 
managing  the  utilization  of  rules  is  called  a  goal  driven  control  strategy,  or 
backward  chaining,  inasmuch  as  it  selectively  pursues  one  goal  at  a  time. 
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A  data  driven  control  strategy,  or  forward  chaining,  is  one  in 
which  rule  activation  is  controlled  by  data  available  and  not  by  the  pursuit  of 
particular  goals.  In  the  data  driven  approach  the  expert  system  awaits  the 
input  of  new  data.  When  new  data  is  entered,  the  inference  engine  scans  for 
rules  that  are  impacted,  applies  the  impacted  rules  to  generate  whatever 
conclusion  it  can,  and  then  resumes  waiting  for  input. 

c.  Knowledge  Engineering 

Expert  systems  can  be  described  as  computer-consultants  that 
emulate  human  expert  reasoning  in  a  problem  domain.  The  process  of 
extracting  and  encoding  domain  knowledge  held  by  human  expertise  is  called 
knowledge  engineering.  Today,  knowledge  engineering  remains  a  time- 
consuming  and  labor-intensive  process  wherein  an  AI  technologist,  called  a 
knowledge  engineer,  must  repeatedly  interview  one  or  more  human  experts 
over  a  long  time  period  to  extract  the  heuristics  to  be  encoded  in  the  expert 
system  knowledge  base. 

d.  Limitations  of  Expert  Systems  Technology 

Expert  system  technology  provides  a  powerful  set  of  tools  for 
developing  systems  that  can  generate  expert  advice  to  users  for  solving 
important  and  complex  problems.  Unfortunately,  there  are  a  number  of 
practical  difficulties  exist  in  the  system.  The  following,  drawn  from  Barr, 
Cohen,  and  Feigenbaum  (1989),  represents  a  typical  characterization  of  these 
limitations. 

•  Narrow  Domain  of  Expertise.  Expert  systems  work  within  narrow  areas 
of  expertise  (Davis,  1982  and  1989).  Technical  domains,  in  which  terms 
are  well  defined  and  in  which  subprograms  can  be  solved  separately,  are 
more  amenable  to  introduction  of  expert  systems  than  more  open- 
ended  domains.  Engineering  and  business  are  thus  better  problem 
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domains  than  political  science  and  sociology.  When  the  limitations  are 
well  understood,  there  is  little  problem  in  using  an  expert  system 
reliably  for  substantial  gains  in  productivity,  and  many  of  the  notable 
successes  are  of  just  this  sort  (Feigenbaum,  1989). 

•  First  Principles.  The  domain  models  used  by  expert  systems  are  not 
generally  the  theoretical  first  principles  of  textbooks,  but  are  a  looser 
collection  of  facts  and  associations  (Davis,  1987).  Expert  systems  rely 
more  on  special-case  formulations  of  relations  than  on  "first 
principles."  Although  a  set  of  general  principles  such  as  Maxwell’s 
equations  governs  the  behavior  of  a  large  class  of  devices,  designers  of 
expert  systems  prefer  to  codify  special  cases,  exceptions,  and  empirical 
associations,  as  well  as  some  causal  associations,  in  order  to  put  the 
general  principles  in  forms  that  can  be  applied  more  quickly  and  more 
precisely.  As  a  result,  they  are  unable  to  fall  back  on  a  better  theory  in 
some  situations.  There  is  substantial  research  in  AI  on  using  first 
principles  in  reasoning,  much  of  it  in  the  area  of  electronics 
troubleshooting  (Davis,  1987).  As  this  matures,  it  will  allow  us  to  build 
expert  systems  that  blend  the  theoretical  soundness  of  the  first 
principles  with  the  precision  of  special-case  exception  clauses  that  map 
the  theory  into  the  world  of  practical  applications. 

•  Limits  of  Knowledge.  Expert  systems  tend  to  perform  well  on  the  classes 
of  cases  that  have  been  explicitly  considered  but  may  fail  precipitously  in 
new  cases  at  the  boundaries  of  their  comp>etence  (Davies,  1987;  Lenat, 
1986).  In  part  this  is  due  to  lack  of  knowledge  of  first  principles.  The 
performance  of  humans  is  more  robust.  As  we  reach  the  extent  of  what 
we  know  about  a  problem  area,  we  often  can  give  appropriate  answers 
that  are  approximately  correct,  although  not  very  precise,  and  we  know 
that  we  have  reached  the  limits  of  our  knowledge.  For  expert  systems, 
the  standard  solution  today  is  to  codify  rules  that  screen  out  cases  that 
are  outside  the  intended  scope  in  order  to  further  ensure  that  the  system 
is  being  used  in  an  appropriate  way. 

•  Self-knowledge.  Expert  systems  have  little  or  no  self-knowledge,  and 
thus  do  not  have  a  sense  of  what  they  do  not  know  (Lenat  et  al.,  1983). 
Although  expert  systems  can  often  give  explanations  of  what  they 
know,  they  do  not  have  a  general  "awareness"  of  what  the  scope  and 
limitations  of  their  own  knowledge  are.  Meta-level  knowledge,  such  as 
rules  of  strategy,  can  offset  this  shortcoming  in  special  situations  but 
does  not  constitute  a  general  capability. 

•  Commonsense  Knowledge.  Expert  systems  can  only  represent 
commonsense  knowledge  explicitly  and  do  not  use  commonsense 
modes  of  reasoning  such  as  analogical  reasoning  or  reasoning  from  the 
most  similar  recent  case  (McCarthy,  1983).  Designer  of  current  expert 
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systems  resolve  this  by  assuming  that  users  can  exerdse  some  common 
sense,  and  by  specifying  common  facts  explidtly  when  needed. 

•  Explicit  Knowledge.  The  knowledge  of  expert  systems  must  be  made 
explicit;  they  have  no  intuition  (Dreyfus  and  Dreyfus,  1986).  So  far,  the 
problems  that  have  been  most  successfully  solved  with  expert  systems 
have  been  those  in  which  inferential  knowledge  is  easily  formulated  as 
rules  and  the  organization  of  objects  and  concepts  is  easily  formulated  as 
taxonomic  (class-subclass-instance)  hierarchies  and  part-whole 
hierarchies.  Reasoning  by  analogy  of  by  intuition  is  still  too 
unpredictable  to  use  in  high-performance  systems.  Because  expert 
systems  articulate  what  they  know.  Any  task  for  which  knowledge 
cannot  be  articulated  for  any  reason  is  not  a  food  candidate  for  an  expert 
system. 

•  Reusable  Knowledge.  Knowledge  bases  are  not  reusable  (Lenat,  1986). 
Since  the  cost  of  building  a  knowledge  base  is  substantial,  it  is  desirable 
to  amortize  it  over  several  related  expert  systems,  with  unique 
extensions  to  cover  unique  circumstances.  For  example,  many  medical 
systems  use  facts  about  anatomy  and  physiology,  yet  often  each  encodes 
those  facts  specifically  for  use  in  a  unique  way.  The  challenge  is  to 
develop  knowledge  representations  that  can  be  used  efficiently, 
independent  of  the  specific  context  of  use.  By  contrast,  considerable 
progress  has  been  made  in  building  lower  level  components  of  expert 
systems  that  are  reusable  -  this  has  led  to  the  widespread  use  of  expert 
systems  shells.  Representing  knowledge  in  structure  objects  improves 
the  chances  of  reusability,  and  substantial  current  research  is  exploring 
this  and  other  means  of  improving  reusability  of  knowledge  bases  (see, 
for  example,  Lenat,  1986). 

•  Learning.  Expert  systems  do  not  learn  form  experience  (Schank,  1983). 
Research  on  machine  learning  is  maturing  to  the  point  where  expert 
systems  will  be  able  to  learn  from  their  mistakes  and  successes.  Learning 
by  induction  from  a  large  library  of  solved  cases  is  already  well  enough 
understood  to  allow  induction  systems  to  learn  classification  rules  that 
an  expert  system  then  uses  (Michie  et  al.,  1984;  Michalski  et  al.,  1986). 
Prototype  systems  have  been  built  that  emphasize  learning  in  context, 
sometimes  called  explanation-based  learning  or  apprentice  learning, 
which  appears  to  hold  promise  for  expert  systems  (Mitchell  et  al.,  1986). 
The  challenge  is  to  design  learning  mechanisms  that  are  as  accurate  as 
knowledge  engineering  but  are  more  cost  effective. 

•  Reasoning  Methods.  It  is  generally  not  p>ossible  to  prove  theorems  about 
the  scope  and  limits  of  an  expert  system  because  the  reasoning  is  not 
formal  (Nilsson,  1982).  Although  some  systems  are  implemented  in  a 
logic  programming  language  such  as  Prolog,  or  otherwise  use  predicate 
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calculus  as  a  representation  language,  many  systems  are  more  "ad  hoc." 
In  this  regard,  though,  expert  systems  are  not  in  a  much  different  state 
than  other  software  in  which  complex  reasoning  with  heuristics  defies 
proofs  of  correctness.  There  is  considerable  research  in  formalizing  the 
reasoning  methods  of  AI  programs  and  combining  those  with  a 
predicate  calculus  representation  of  knowledge. 

•  Knowledge  Context.  Expert  systems  may  fail  if  the  user's  conceptual 
framework  is  not  the  same  as  that  of  the  expert  and  others  on  the  design 
team  (Winograd  and  Flores,  1986).  Knowledge  engineers  work  under 
the  assumption  that  the  experts  they  work  with  know  the  context  of 
intended  use  and  the  intended  users'  terminology  and  point  of  view. 
This  may  result  in  misuse  of  a  system  when  a  user  attaches  different 
meaning  to  terms  than  did  the  expert  who  designed  the  knowledge  base. 
There  are  no  safeguards  built  into  today's  systems  to  test  this 
assumption.  Thus  the  challenge  is  to  provide  enough  ways  of 
explaining  what  is  in  a  knowledge  base  to  make  its  contents  clear  to  all 
users.  But  a  simple,  more  pragmatic  remedy  is  to  include  members  of 
the  intended  user  community  on  the  design  team.  A  related  problem  is 
that  the  conceptual  view  of  the  design  team  —  even  if  only  a  single 
expert  -  may  change  over  time,  and  thus  maintaining  a  knowledge  base 
over  time  becomes  difficult. 

B.  EXPERT  SYSTEM  IN  MILITARY  APPLICATIONS 

The  term  "intelligence"  as  used  in  expert  systems  for  military  applications 
refers  to  the  collection,  correlation  and  analysis  of  information  to  support 
command  decision-making  (Lehner,  1989,  p.  95).  Time  is  always  critical  in  a 
war  at  sea.  A  commanding  officer  in  a  combat  situation  must  react  efficiently 
and  effectively  in  an  environment  that  is  both  time  critical  and  tactically 
complex.  A  well  functioning  expert  system  can  render  incalculable  assistance 
to  that  commander  by  aiding  in  making  both  rapid  and  correct  decisions, 
thereby  significantly  reducing  the  incidence  of  strategic  and/or  tactical  errors 
in  critical  situations.  In  the  following  sections,  we  summarized  some  military 
applications  using  AI  technology  as  detailed  in  (Lehner,  1989). 
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1.  Large  Area  Sensor  Surveillance  System 

The  Automated  Exploitation  of  Large  Area  Surveillance  Sensor 
(AELASS)  system  is  a  production  rule  system  developed  by  PAR  Government 
Systems  Corporation,  for  identifying  the  activities  of  military  units  based  on 
surveillance  data  that  is  provided  from  a  variety  of  collection  devices 
(Lehner,  1989,  p.  97). 

2.  Electronic  Intelligence  System 

The  Expert  Prolog  System  (EXPRS)  work,  as  described  in  Pecora  (1984), 
is  oriented  toward  developing  a  general  class  of  techniques  that  can  be  applied 
to  the  full  spectrum  of  problems  in  tactical  fusion  (Lehner,  1989,  p.  101). 

3.  A  Tactical  Aid  for  Estimating  Courses  of  Action 

AI/ECONA  is  a  prototype  decision  aid,  developed  by  PAR 
Government  Systems  Corporation,  that  is  designed  to  assist  Army  tactical 
intelligence  analysis  in  evaluating  alternative  Enemy  Course  of  Action 
(COAs).  AI/ENCOA  combines  the  use  of  additive  multiattribute  utility 
analysis  (MAU)  for  course  of  action  evaluations  with  rule-based  procedures 
for  assigning  parameter  values  (scores  and  weight)  to  the  MAU  model 
(Lehner,  1989,  p.  106). 

4.  Real-Time  Advisory  System 

The  Real-Time  Advisory  System  (RTAS)  is  a  prototyp)e  expert  system 
that  operates  as  an  intelligent  interface  system.  It  is  designed  to  provide  real¬ 
time  tactical  advice  for  Airborne  Antisubmarine  Warfare  (AASW)  problems 
(Lehner,  1989,  p.  133). 
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5.  A  Fire  Support  Planning  Aid 

Battle  is  a  decision  aid  designed  to  assist  fire  support  planning,  and 
was  developed  by  Slagle  and  Hamburger  (1985)  while  at  the  Navy  Center  for 
Applied  Research  in  Artificial  Intelligence  (Lehner,  1989,  p.  148). 
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in.  RELATED  WORK 


A.  INTRODUCTION 

A  great  deal  of  energy  and  effort  is  presently  directed  towards  research  and 
application  of  AI  technology.  The  effort  involves  development  and 
refinement  of  both  hardware  and  software  that  can  be  of  assistance  in 
overcoming  the  difficult  and  complex  problems  that  are  of  immediate 
concern,  and  also  those  sets  of  problems  which  are  anticipated  for  future 
encounters. 

A  number  of  officers  who  have  studied  at  the  Naval  Postgraduate  School 
are  currently  involved  in  the  concentrated  research  that  falls  within  the  scope 
of  AI  technology.  Using  both  experimental  data  and  their  on  board  training  in 
an  effort  to  further  the  efficacy  of  AI  systems  in  battlefield  applications. 

B.  REVIEW 

1.  Adaptation  of  a  Knowledge  Based  Decision-Support  System  in  the 

Tactical  Environment 

In  a  paper  presented  by  Clair,  and  Danhof  (1981),  the  authors  describe 
an  alternative  to  the  system  then  in  use  (e.g  the  World  Wide  Military 
Command  and  Control  System,  and  the  Naval  Tactical  Data  System),  which 
the  authors  determined  to  be  too  slow,  too  large,  and  too  expensive,  therefore 
rendering  it  impractical  for  the  tactical  environment  of  1981. 

Clair  and  Danhof  designed  a  replacement  which  they  designated  as  a 
TAC*  system,  for  "Tactical  Adaptable  Consultant."  The  new  system 
incorporated  a  database,  a  knowledge  base,  their  associated  management 
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systems,  and  a  distributed  interface,  and  could  assist  tactical  commanders  in 
decision  making. 

Many  computer  systems  have  been  designed  for  specific  problems. 
The  result  of  such  systems  is  limited  application  areas.  While  the  original 
concept  of  TAC*  was  to  provide  a  tool  for  the  tactical  commander,  the 
ultimate  design  was  conceived  to  be  general  in  nature.  Due  to  the  method  of 
treating  data,  rules,  and  changes  as  identical  functions  within  the  design 
structure,  the  basic  system  may  be  used  in  any  number  of  other  application 
areas. 

2.  TAC^II  an  Expert  Knowledge  Based  System  for  Tactical  Decision 

Making 

TAC*II  (Geschke,  Bullock  and  Widmaier,  1983)  is  a  redesign  and 
partial  implementation  of  an  expert  AI  sys'  lor  TAG*.  The  system  receives 
preprocessed  sensor  inputs,  letermines  what  contacts  are  present,  and 
suggests  the  best  course  of  action  to  take.  It  performs  target  analysis  and 
correlation  based  upon  the  current  tactical  situation.  Production  rules  are 
used  to  discover  which  actions  have  been  established  by  higher  authority  for 
the  current  tactical  situation.  In  a  highly  dynamic  tactical  environment,  the 
major  emphasis  is  placed  on  one  Naval  Officer,  the  Tactical  Action  Officer 
(TAO).  The  TAO  is  required  to  respond  to  a  vast  c.nount  of  diverse 
information,  received  from  a  multitude  of  sources,  in  an  extremely  time 
critical  situation.  The  system  which  they  proposed  is  an  automated  aid  to  the 
TAO,  a  decision  making  system  which  can  assist  the  officer  to  respond  in  a 
timely  manner  to  the  current  situation. 
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To  date  it  has  not  been  sufficiently  verified  that  the  TAC*II  system 
can  operate  within  and  meet  the  real  time  requirements  of  the  tactical 
environment.  Though  the  system  designers  believe  that  operational 
efficiency  within  real  time  is  a  realistic  expectation  of  their  system,  their 
design  goals  did  not  incorporate  real  time  functions  within  the  prototype 
base,  but  rather  designed  a  system  that  performed  the  required  functions. 

3.  A  Rule-Based  System  for  Shipboard  Air  Defence 

Wang  (Wang,  1989)  asserts  that  because  of  the  changes  in  warfare  that 
have  occurred  since  War  World  II,  today’s  navies  are  facing  an 
unprecedented  challenge  at  sea.  The  reasons  for  building  and  proliferating 
expert  systems  as  aids  to  the  decision  making  process  in  tactical  air  defense  are 
as  follows: 

•  The  increased  speed  of  weapons  systems  has  reduced  the  time  available 
for  making  tactical  decisions  by  human  decision  makers.  This  requires 
greater  capabilities  to  meet  the  incoming  threats  and  can  be  partially 
automated  through  the  use  of  computers. 

•  Weapons  technology  has  progressed  to  a  point  where  it  is  very  difficult 
for  a  single  human  decision  maker  to  be  proficient  in  all  offensive  and 
defensive  options;  additionally,  there  may  not  be  enough  time  for  him 
to  absorb  all  information  and  execute  all  decisions  without  any  error. 

•  In  the  area  of  military  tactical  operations,  knowledge  and  data  are  closely 
related  in  the  decision  making  process. 

•  A  tactical  situation  is  usually  presented  to  the  OTC  (Officer  in  Tactical 
Command)  with  a  view  of  the  "state  of  the  world."  This  view  can  be 
inaccurate.  Nonetheless,  based  on  this  incomplete  information  he  must 
make  decisions  subject  tc  the  constraints  imposed  by  preplanned 
actions. 

The  above  statements  illustrates  the  need  for  using  an  intelligent 
expert  system  to  assist  the  OTC  in  executing  the  decision  making  process.  The 
system,  in  common  with  the  two  systems  previously  discussed,  receives 
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preprocessed  sensor  input,  performs  target  analysis  and  correlation  based  on 
current  tactical  situ,  tion,  and  suggests  the  best  optimal  course  of  action. 

The  paper  also  shows  the  computer  simulation  results. 

C  SUMMARY 

All  three  papers  discussed  above  address  the  issue  of  designing  an  expert 
system  to  aid  the  responsible  party  (i.e.  TAO  or  OTC)  in  problem  solving 
within  the  environment  of  hostile  engagement. 

We  would  like  to  point  out  and  emphasize  additional  requisite 

characteristics  of  these  systems  as  the  following: 

•  All  the  systems  need  data  input  from  the  out  side  world  (i.e  sensors, 
information  network,  or  human  interface  e.t.c). 

•  All  the  systems  have  to  have  the  ability  to  analyze  a  very  large  amount 
of  data  in  an  extremely  short  time. 

•  All  the  systems  must  possess  large  memory  to  store  the  dynamic  data  in 
a  complex  environment. 

•  All  the  systems  must  not  only  give  correct  advice,  but  must  make  that 
advice  available  as  fast  as  possible. 
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IV.  DEHNING  A  WEAPON  SUGGESTION  SYSTEM 


A.  WEAPON  SUGGESTION  SYSTEMS 

1.  Definition 

The  Weapon  Suggestion  System  (WSS)  is  a  system  to  assist  human 
analysts  in  difficult  battle  conditions.  Inherent  within  both  its  design  and 
capability  is  the  capacity  to  process  information  and  arrive  at  conclusions 
under  conditions  which  are  difficult  for  humans.  Using  relative  data  collected 
from  the  incoming  target  itself  the  WSS  has  the  capacity  to  identify  and 
classify  the  threat  from  that  incoming  target.  Analyzing  all  the  related  data 
stored  in  the  knowledge  base  the  system  is  subsequently  able  to  formulate  and 
suggest  an  optimal  response  utilizing  installed  weapons  systems. 

2.  Why  Build  the  System? 

At  present  surface  ships  may  well  expect  to  confront  a  widely  varying 
conformation  of  enemy  strike  weapons  directed  against  it.  This  variety  and 
complexity  of  offensive  weapons  is  further  compounded  by  the  daily 
improvements  made  in  offensive  weapon’s  systems.  These  two  factors  may 
then  again  be  multiplied  by  the  potential  of  rapidly  changing  battle  conditions 
due  to  the  enhanced  time  frame  delivery  capabilities  of  todays  modern 
weapons. 

Putting  these  factors  together  and  viewing  them  in  a  realistic  light,  it 
can  be  safely  said  that  an  officer’s  ability  to  assess  all  relevant  technological 
data  and  arrive  at  the  response  within  the  critical  time  allotments  has  been 
outstripped  by  the  mass  of  the  technology  itself. 
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The  WSS  is  specifically  designed  to  protect  against  that  technological 
vulnerability.  By  assisting  the  WDH  on  board  in  optimal  weapons  selection 
against  hostile  targets  the  survivability  of  a  ship  and  its  crew  can  be  greatly 
enhanced. 

B.  MAIN  STRUCTURE  OF  WSS 

1.  Functions 

The  WSS,  as  previously  mentioned,  is  used  to  suggest  the  best 
available  weapons  on  board  that  can  be  used  against  the  enemy  targets  within 
a  specified  period  of  time.  Ideally,  WSS  can  analyze  any  number  of  targets  of 
different  types,  which  may  appear  simultaneously  or  at  varying  times,  then 
generate  the  appropriate  suggestions  and/or  instructions  regarding  weapon 

deployment.  The  functions  of  WSS  are: 

•  Decreasing  the  reaction  time  for  weapon  selection  in  time  critical 
situations 

•  Generate  a  set  of  weapon  suggestion  instructions 

•  Producing  a  automatic  weapon  assignment  system  which  significantly 
reduces  reaction  time  and  the  probability  of  miscalculation  when  used 
with  sensors,  identification  devices  and  an  operational  combat  system 

•  Decreasing  the  probability  of  human  error  in  the  complex  war  at  sea 
conditions 

2.  Peripheral  Devices  of  the  WSS 

An  ideal  WSS  is  equipped  with  sensors,  IFF  devices,  modem  combat 
systems,  and  weapons.  The  combat  system  has  the  capability  of  arranging  the 
firing  order  of  the  on  board  weapons,  while  the  Identify  Friend  or  Foe  (IFF) 
device  can  assist  in  differentiating  and  classifying  targets.  The  sensors  are  used 
primarily  to  detect  targets. 
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Initially,  the  WSS  receives  the  preprocessed  input  signals  from  the 
sensors  (i.e.  ESM,  Radar,  Sonar,  vision  etc.),  performs  target  analysis  and 
correlation  based  on  the  ciurent  tactical  situation,  and  subsequently  generates 
the  optimal  weapons  selection  instructions  which  feed  into  the  combat 
system.  Figure  4-1  showed  the  peripheral  devices  of  the  WSS. 


Figure  4-1.  Peripheral  Devices  of  WSS 


a.  Sensors 


Sensors  are  devices  that  can  detect,  measure  or  record  physical 

phenomena.  In  the  simulation  we  assume  we  have  the  following  sensors: 

•  Radar:  a  device  using  transmitted  and  reflected  radio  waves  for 
detecting  a  reflecting  object  (such  as  an  aircraft)  and  determining  its 
direction,  distance,  height,  or  speed. 

•  ESM  (Electrical  Support  Measure):  a  passive  device  employed  to 
intercept  the  radio  waves  from  the  active  sources. 

•  Sonar:  an  apparatus  that  transmits  high-frequency  sound  waves 
through  water  and  registers  the  vibrations  reflected  from  an  object,  used 
in  finding  submarines,  depths,  etc. 

•  Vision:  the  act  or  power  of  seeing  with  the  eye. 

The  parameters  of  each  sensor  are  described  in  Table  4-1.  The 
values  in  Table  4-1  are  approximate  number. 
b.  Weapons 

Weapons  are  instruments  or  devices  used  to  injure,  kill  or 

destroy  an  object.  We  assume  we  have  the  following  weapons  in  WSS: 

•  SAM  (Surface  to  Air  Missile):  an  anti-aircraft  and  anti-missile  weapon. 
It  provides  primary  air  defense  for  the  warship. 

•  76  mm  (76  nun  gun):  a  gun  whose  main  role  is  anti-missile  defense  but 
it  is  also  effective  in  either  anti-aircraft  or  anti-ship  fire. 

•  40  mm-1,  40  mm-2  (40  mm  gun):  effective  in  either  anti-aircraft  or  anti¬ 
ship  fire  but  the  maximum  firing  range  is  significantly  shorter  than  the 
76  mm  gun. 

•  CIWS  (Close-In  Weapon  System):  to  provide  last  ditch  defense  against 
anti-ship  missile.  It  also  provides  continuous  surveillance  and  defense 
within  its  engagement  envelope,  independent  of  other  weapon’s 
systems. 

•  SSM  (Surface  to  Surface  Missile):  an  anti-ship  weapon  which  can  be 
laimched  from  the  surface  ship. 

•  ASROC  (Anti-Submarine  Rocket):  an  ship-launched  ballistic  missile 
used  as  the  primary  anti-submarine  warfare  weapon. 
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•  ASW/torpedo-1,  ASW/torpedo-2;  an  anti-submarine  weapon  which 
can  be  launched  from  the  surface  ship.  Its  maximum  firing  range  is 
significantly  shorter  than  ASROC. 

The  parameters  of  each  weapon  are  described  in  Table  4-2.  The 

values  in  the  table  are  approximate  number. 


TABLE  4-1.  SENSOR  PARAMETERS  IN  WSS 


ITEM 

detection  range 
(mile) 

surveillance  sector 
(degree) 

application 

Radar 

0-300 

0-360 

air,  surface 

ESM 

0-400 

0-360 

air,  surface 

Sonar 

0-30 

0-360 

subsurface 

Vision 

0-10 

0-360 

air,  surface 

TABLE  4-2.  WEAPON  PARAMETERS  IN  WSS 


ITEM 

firing  range 
(mile) 

firing  sector 

(degree) 

application 

SAM 

3-30 

0-360 

air 

76  mm 

0.1-8 

0-360 

air,  surface 

40  mm-1 

0.01  -  3 

60-120 

air,  surface 

40  mm-2 

0.01  -  3 

240  -  300 

air,  surface 

CIWS 

0-1.5 

0-360 

air,  surface 

SSM 

5-200 

0-360 

surface 

ASROC 

3-12 

0-360 

subsurface 

ASW/torpedo- 1 

0-5 

60-120 

subsurface 

ASW/torpedo-2 

0-5 

240  -  300 

subsurface 

3.  Outline  of  the  Weapon  Suggestion  System 


The  WSS  is  a  software  system  which  is  implemented  in  KEE  (see 
Chapter  V  for  detail).  We  will  discuss  the  implementation  and  simulation  of 
the  system  in  Chapter  V.  The  flow  chart  of  the  system  are  presented  in  the 
Appendix.  The  working  steps  of  WSS  are  described  below: 
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•  As  the  targets  fall  into  the  surveillance  area  of  the  sensors,  the  sensor 
network  will  generate  such  data  as  speed,  distance,  height,  depth,  and 
direction,  for  each  potential  target  and  input  that  information  into  the 
WSS  database. 

•  Based  on  IFF  signals  and  an  interpretation  of  the  information  received, 
the  WSS  will  identify  the  potential  targets  as  friendly  or  hostile.  If  the 
target  IFF  signal  corresponds  to  a  known  USN  or  allied  reference,  the 
target  will  be  identified  as  such.  Otherwise  it  will  be  automatically 
identified  as  a  "hostile"  target. 

•  Classification  of  the  threat  class  of  the  hostile  target.  The  threat  class  will 
be  generated  and  determined  from  the  threat  value  equation  which  is 
integrally  programmed  into  WSS.  (The  threat  value  equation  will  be 
discussed  in  Chapter  V.) 

•  Generate  the  weapon  suggestion  instruction.  After  the  target  has  been 
identified  as  "hostile"  and  its  potential  threat  assessed,  the  WSS  will 
suggest  the  weapons  to  be  most  effectively  deployed  when  the  target 
distance  has  closed  to  within  maximum  firing  range.  Then,  the  WSS 
will  suggest  that  weapon  for  use  against  the  target.  All  the  above 
procedures  of  the  WSS  tire  performed  automatically. 

•  If  a  target  has  been  neutralized  or  destroyed  or  any  new  targets  appear, 
the  system  can  immediately  regenerate  the  new  weapon  suggestion 
instructions  upon  request. 

•  The  WSS  can  generate  an  output  signal  from  the  selected  weapon  while 
it  is  being  deployed  against  the  hostile  target,  and  the  combat  system  will 
display  the  relative  status  of  each  weapon,  whether  it  is  deployed,  in 
readiness  or  held  in  reserve.  The  combat  system  will  generate  and 
execute  gun  orders  for  the  on  board  weapons,  as  well  as  performing  the 
tracking  and  readiness  inventory  functions.  Once  the  WDH  has  agreed 
to  the  weapon  suggestion  of  the  WSS,  the  weapon  will  be  assigned  and 
positioned  to  fire  through  the  combat  system. 

4.  Limitations 

Although  a  WSS  can  perform  many  functions  and  solve 
innumerable  problems,  it  is  in  fact  linuted  by  the  fixed  number  of  sensors  and 
weapons  on  board  any  given  vessel,  as  well  as  by  the  differing  performance  of 
those  weapons  and  sensors.  Consequently,  we  believe  the  following  factors 
should  be  considered  when  designing  the  WSS  for  a  specified  platform. 
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a.  Tactical  Limitation 

As  we  build  the  WSS  we  need  to  give  detailed  consideration 
towards  defining  the  exact  tactical  parameters  of  that  specified  system.  Each 
platform  can  and  will  be  expected  to  perform  entirely  different  functions 
within  a  context  of  hostile  engagement.  If  the  fundamental  design  and 
programming  decisions  have  been  ill-conceived  with  regard  to  tactical 
specialization,  the  systems  will  not  only  be  useless  but  may  also  expose  the 
platform  to  potentially  disastrous  consequences. 

b.  Sensor  Limitation 

Before  we  design  a  weapon  suggestion  system  for  a  specific 
platform  we  need  to  give  careful  consideration  to  the  following  factors  that 
limit  sensors  and  which  will  directly  impact  upon  a  vessel  capability  to  detect 
targets. 

•  The  detection  range  of  the  sensor 

•  The  blind  zones  of  the  sensor 

•  The  capability  of  sensors  for  tracking  multiple  target  simultaneously 

•  The  number  of  sensors  that  can  be  installed  in  the  platform 

•  The  characteristics  of  the  sensor  (i.e  for  air,  surface  or  subsurface 
surveillance) 

c.  Weapon  Limitation 

Weapons  manufactured  to  the  same  mechanical  specifications  of 
exactly  the  same  type  and  model,  installed  on  exactly  the  same  type  of  vessel 
can  be  expected  to  perform  quite  differently  due  to  such  minor  variables  as 
firing  position.  Because  of  this  variability  in  weapons  performance,  the 

following  limitation  factors  need  to  be  considered  as  we  build  the  system. 

•  The  effective  firing  range  of  the  weapon 

•  The  "firing  cut  out"  zones  of  the  weapon 
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•  The  number  of  weapons  in  the  platform 

•  The  destructive  capacity  of  the  weapon 

•  The  relative  priority  of  the  weapon  for  deployment  against  an  enemy 
target 

•  The  characteristic  of  the  weapon  (i.e  Surface  to  Air,  Surface  to  Surface, 
or  Surface  to  Subsurface) 
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V.  CONSTRUCTING  A  WEAPON  SUGGESTION  SYSTEM 


A.  THE  APPLICATION  DEVELOPMENT  ENVIRONMENT 

1.  Introduction 

The  WSS  was  designed  and  implemented  in  the  Knowledge 
Engineering  Environment  (KEE)  on  a  Texas  Instruments  Explorer 
workstation.  The  tools  and  facilities  in  KEE  that  we  used  in  the  development 
are  described  below.  KEE  terminology  is  also  essential  for  understanding  later 
description  of  the  applications. 

2.  Knowledge  Engineering  Environment 

The  KEE  (KEE  Activelmage  Reference  Manual,  1989,  KEE  Interface 
Reference  Manual,  1987,  KEE  TellAndAsk  Reference  Manual,  1989,  KEE 
User's  Manual,  1988)  provides  knowledge  system  developers  with  a  set  of 
programming  tools  and  techniques  for  building  applications  to  represent  and 
utilize  knowledge.  Knowledge  systems  are  an  important  part  of  programming 
technology.  They  have  evolved  to  improve  the  way  that  people  and 
computers  interact.  KEE  is  built  upon  Lisp  and  supports  object  oriented 
programming.  It  also  includes  a  graphical  user  interface.  The  following 
sections  introduce  basic  features  of  KEE. 

a.  Objects,  Attributes  and  Values 

To  set  up  a  knowledge  base  in  KEE  one  must  first  define  the 
objects  and  their  attributes  and  values.  An  object  is  an  entity  or  an  item  that 
represents  a  physical  object  such  as  a  ship,  a  person,  or  a  weapon;  or  it  could 
be  an  abstract  idea  or  a  concept.  Objects  can  be  organized  in  hierarchical 
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structures  to  represent  classes  and  members.  Attributes  and  values  are 
properties  that  describe  a  class  of  objects,  a  subclass,  or  a  member  object.  In 
KEE,  the  value  of  an  attribute  can  be  integers,  symbols,  objects,  classes  of 
objects,  and  methods  (Lisp  functions).  In  order  for  the  value  of  an  attribute  to 
be  a  function,  the  value  class  of  the  attribute  must  be  declared  as  a  method. 
Methods  are  behavioral  knowledge  made  up  of  Lisp  code  used  to  retrieve 
information  or  to  modify  the  knowledge  base.  Once  a  method  is  written,  it  is 
stored  as  the  value  of  an  attribute.  It  does  nothing  until  it  is  activated. 

b.  Inheritance 

The  units  are  grouped  into  hierarchies  from  more  general  objects, 
called  classes,  down  to  particular  objects,  called  instances.  A  unit  is  made  up 
of  slots  created  to  represent  an  object’s  attributes.  Designers  can  describe  a 
system  by  creating  units  that  act  as  templates  for  a  whole  class  of  objects. 
When  a  new  unit  is  designated  a  "child"  of  one  or  more  units,  it  inherits  slots 
and  default  information  from  its  "parents.”  One  can  then  add  objects  or 
modify  the  inherited  information  as  needed  to  reflect  the  values  of  an  object. 

c.  Rules 

Rules  are  classified  as  a  special  type  of  object.  Like  other  objects, 
rules  have  classes,  subclasses,  and  members.  Unlike  other  objects,  we  define 
the  rules,  not  the  attributes.  In  KEE,  rules  are  written  as  if-then  statements. 
The  "if"  part  of  a  rule  consists  of  a  set  of  conditions,  called  the  premises;  when 
the  premises  are  satisfied,  facts  contained  in  the  "then"  part  of  the  rules, 
called  the  conclusion,  are  activated,  and  actions  specified  in  the  conclusion 
performed.  KEE  allows  the  user  to  partition  rules  by  grouping  them  into  rule 
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classes.  This  increases  the  system  efficiency  by  reducing  CPU  time  for  pattern- 
matching  routines  and  user  maintenance  time. 

KEE  provides  two  types  of  rules  for  the  designer:  deduction  rules 
and  action-taking  rules.  Both  types  are  needed  depending  upon  whether  the 
user  requires  rules  that  perform  deduction  and  rules  that  take  some  kind  of 
action  on  the  system  objects.  Deduction  rules  are  pure  theorem-proving  rules. 
They  establish  dependencies  between  a  conclusion  and  its  premises.  If  the 
rules  produce  a  contradiction  to  the  set  of  facts  that  the  system  started  out 
with,  then  the  original  facts  are  inherently  contradictory  or  the  rules  are 
inconsistent.  Action-taking  rules,  on  the  other  hand,  change  the  knowledge 
base  of  the  application. 

d.  TellAndAsk 

TellAndAsk  is  an  English-like  language  that  can  be  used  to 
interact  with  KEE.  It  can  be  used  for  a  variety  of  purposes  such  as  modifying 
knowledge  bases,  writing  rules,  creating  justifications,  and  putting  facts  into 
worlds.  TellAndAsk  is  a  language  with  a  syntax  similar  to  English  and 
provides  a  way  of  making  statements  about  relationships  between  units, 
values  of  slots,  and  values  of  facets. 

e.  Active  Values 

Active  values  are  "watchdog"  units.  They  provide  the  facility  to 
cause  side  effect  behavior  when  accessing  or  modifying  data  in  a  knowledge 
base.  By  attaching  an  active  value  to  a  slot,  the  designer  can  specify  that  a 
particular  action  should  occur  every  time  that  slot’s  value  is  accessed  or 
modified. 


29 


/.  Activelmages 

KEE's  Activelmages  package  provides  a  variety  of  graphic 
displays  for  both  viewing  and  modifying  slot  values  in  KEE  obiects.  These 
graphic  images  can  be  integrated  into  an  application  as  an  attractive  interface 
to  the  system.  They  also  can  be  used  during  application  development  as  a 
convenient  display  aid  for  program  debugging.  There  are  many  different 
kinds  of  images,  including  histograms,  push  buttons,  thermometers, 
numeric-dials,  and  plots. 

g.  KEEworlds 

KEE's  multiple  worlds  facility  enables  one  to  assert  a  collection  of 
facts  into  a  single  context,  called  the  backgroimd,  which  can  be  used  as  a  basis 
for  the  creation  of  additional  worlds  containing  somewhat  different  facts  and 
assumptions.  KEEworlds  is  useful  for  modeling  and  exploring  different 
hypothetical  situations  that  might  arise  in  a  knowledge  base.  A  new  world 
represents  an  alternative  state  of  new  context  of  a  knowledge  base. 

h.  Truth  Maintenance  System 

If  a  fact  or  assumption  is  no  longer  believed  to  be  true,  the  Truth 
Maintenance  System  (TMS)  makes  sure  any  facts  contingent  upon  the  belief 
are  retracted  from  the  knowledge  base.  These  contingencies  are  called 
justifications.  A  designer  can  use  the  Truth  Maintenance  System  to  perform 
bookkeeping  for  applications  that  incorporate  information  inferred  from 
other  facts  and  assumptions  and  to  help  with  backtracking  to  previous  states. 

i.  KEEpictures 

The  KEEpictures  environment  is  an  objective-oriented  graphics 
tookit  that  enables  designers  to  construct  images  or  graphic  systems, 
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interfaces,  and  end-user  applications.  Its  intended  uses  range  from  simple 
graphical  displays  to  animation.  KEEpictures  provides  a  set  of  standard 
picture  classes  for  picture  construction.  These  include  arcs,  axes,  box.string, 
bitmaps,  circles,  dials,  lines,  and  rectangles.  Each  of  these  primitives  can  be 
shaped,  enlarged,  shrunk,  and  altered  in  a  variety  of  ways.  Pictures  can  be 
combined  to  form  larger,  composites  pictures.  Users  can  also  draw  their  own 
pictures  using  bitmaps. 

2.  Texas  Instruments  Explorer 

The  Texas  Instruments  Explorer  system  is  an  advanced,  single-user 
workstation  that  provides  extensive  support  for  the  development  of  large- 
scale,  complex  programs  and  for  research  in  new  technologies,  including 
artificial  intelligence.  The  Explorer  system  is  also  an  affordable  delivery 
vehicle  for  end-user  applications  requiring  symbolic  processing,  high-quality 
graphics,  and  special-purpose  processors.  The  programming  environment  of 

the  Explorer  system  includes  the  following: 

•  High-resolution,  interactive  display 

•  High-speed  symbolic  processing  using  the  Lisp  and  Prolog  language 

•  Integrated  programming  tools 

•  Extensive  software 

•  Large  memory  capacity  and  sophisticated  memory  management 

•  Networking  facilities 

The  Explorer  system  provides  a  Lisp  environment  of  more  than 
14,000  Lisp  functions.  It  features  a  highly  productive  programming 
environment  that  allows  a  user  to  develop  very  complex  programs  in 
incremental  steps.  One  can  use  any  of  the  system  software,  as  well  as  optional 
toolkits  and  utilities,  as  building  blocks  to  create  application  software.  The 
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Explorer  system  uses  a  variety  of  wii\dows  and  menus  to  present  data  and 
options.  The  window  system  provides  a  hierarchical  input /output  interface 
between  a  user  and  the  Explorer  system.  Different  windows  have  different 
characteristics:  They  can  be  of  various  sizes,  occupy  various  positions  on  the 
video  display,  accept  keyboard  or  mouse  input,  and  display  information. 

The  specially  designed  and  microcoded  Explorer  system  processors 
directly  implement  the  software  run-time  environment,  providing  fast 
execution  of  large  programs  without  sacrificing  the  dynamic  nature  of  Lisp. 
The  Explorer  system  is  written  entirely  in  Lisp. 

B.  SOFTWARE  IMPLEMENTATION 

1.  Introduction 

The  WSS  is  designed  using  KEE.  In  the  following  sections  we  describe 
the  software  implementation  architecture  of  the  Weapon  Suggestion  System 
(WSS). 

2.  Knowledge  Base 

We  created  a  knowledge  base,  and  used  an  arbitrary  name,  in  KEE  for 
the  storage  of  our  WSS.  The  graph  of  the  knowledge  base  is  shown  in  Figure 
5-1.  In  this  section  we  focus  on  RULES.3,  RULES.4,  and  RULES.5  rule  class. 
There  are  four  subclass  rules  in  RULES.3  and  RLUES.4.  The  major  functions 
of  the  subclass  rules  in  RULES.3  are  detection,  identification,  and  the 
classification  of  targets.  The  major  function  of  the  subclass  rules  in  RULES.4  is 
the  suggestion  of  weapons  to  be  used  against  hostile  contacts.  There  are  five 
subclass  rules  in  RULES.5.  These  subclass  rules  are  used  to  process  the  target 
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,  S/A.WlArONJrfHOWlYXXCUANOEJI 
,WtAPONXniOIIITVJ»ULES*;^--  l/S.VfEAPONXWOWI VXItCUANOe.R 
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,  S/A.w 

‘WEAPON4UQaCSTIONJtULES.1<;-><  S^S.W 

'*  i/u.w 

S/A.w  IJICSLECr 


WEATONS*^  >  •  •  -  ASW.TOnPEOO-'t 
V.'v''  ASW.TOBPtOO-2 


eAPON4UnoESTONJ«ULCS.2«^>--  S/S.W2.RESLECT 
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data  and  generate  the  threat  class  of  each  target.  The  rest  of  the  rules  will  be 
discussed  in  the  following  sections.  As  discussed  in  Chapter  IV,  the  step  for 

weapon  suggestion  is  the  following: 

•  Target  detection 

•  Target  identification 

•  Target  classification 

•  Assignment  of  target  threat  class 

•  Suggestion  of  a  proper  weapon  for  use  against  target 

The  rules  are  designed  based  on  the  assumption  that  air  defense 
operations  have  the  highest  priority.  That  is,  if  air  and  surface  targets  appear 
simultaneously,  which  theoretically  could  produce  a  conflict  in  regard  to  the 
weapon  suggestion,  the  air  target  will  be  assigned  priority. 
a.  RULES3  in  Knowledge  Base 

Figure  5-2  shows  the  TARGET.STATUS.RULES  subclass  rule  in 
RULES.3.  It  contains  three  rule  units.  This  subclass  rule  is  used  to  decide 
whether  the  target  is  detected  or  not.  For  example.  To  apply  the 
SENSOR.DETECTED.TARGET.STATUS.RULE  rule,  if  the  following 

conditions  are  true: 

•  Air  target  A1  is  in  class  targets,  and 

•  Siuface  ship  Radar  is  in  class  sensors,  and 

•  The  status  of  surface  ship  Radar  is  on,  and 

•  The  characteristic  of  air  target  A1  equal  to  the  characteristic  of  surface 
ship  Radar,  and 

•  The  sensor  of  DDGB  (Guided  Missile  Destroyer  of  Blue  unit)  is  surface 
ship  Radar,  and 

•  The  relative  range  of  air  target  A1  less  than  or  equal  to  the  maximum 
detective  range  of  surface  ship  Radar, 

then  we  will  reach  the  conclusion  "The  status  of  air  target  A1  is  detected." 
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((IMfORHED. (flRGEI .SIflIUS.RULE 

(IF  (7IRRGET  IS  IN  CLASS  TARGETS) 

(THE  INFORHATION  of  7IARGEt  IS  YES) 

THEN 

(THE  STATUS  OF  7THRGET  IS  DETECTED))) 

(SENSOR. DETECTED. TARGET. STATUS. RULE 
(IF  (7TRROET  IS  IN  CLASS  TARGETS) 

(7SENSOR  IS  IN  CLASS  SENSORS) 

(USP^(EaUAL°(THpCHARRCTERISTIC  OF  7TRRGET)  (THE  CHARACTERISTIC  OF  7SENS0R))) 
(THE  SENSOR  OF  7PLATF0RH  IS  7SEHS0R)  , 

(LISP  (<=  (THE  RELRT  lUE.RAHGE  OF  7TRRGET)  (THE  HAH .  DETECT  I VE  .RANGE  OF  7SENS0R))) 
THEN 

(THE  STATUS  OF  7TARGET  IS  DETECTED))) 

( SENSOR . T  URN . ON . RULE 
(IF  (7TRRGET  IS  IN  CLASS  TARGETS) 

(USP^(<  =  *fTHE  RELRT  lUE.RAHGE  OF  7TRRGET)  (THE  tIAK.  DETECT  I UE.  RANGE  OF  7SENS0R))) 
(LISP  (EQUAL  (THE  CHARACTERISTIC  OF  7TRRGET)  (THE  CHARACTERISTIC  OF  7SENS0R))) 
(THE  SENSOR  OF  7PLHTF0RH  IS  7SEHS0R) 

THEN 

(LISP  (PUT.UALUE  7SENS0R  'STATUS  ’ON))))) 


Figure  5-2.  TARGET.STATUS.RULES  in  RULES.3 


Figure  5-3  shows  the  TARGET.IDENTIFICATION.RULES  subclass 
rule  in  RULES.3.  This  subclass  rule  is  used  to  identify  whether  the  target  is  a 
hostile  or  friendly.  For  example,  to  apple  the 
FOE.TARGET.IDENTinCATION.RULE  rule,  if  the  following  conditions  are 
true: 

•  Air  target  A1  is  in  class  targets,  and 

•  The  status  of  air  target  A1  is  detected,  and 

•  The  IFF  signal  of  air  target  A1  is  different  from  DDGB, 

then  we  can  reach  the  conclusion  "The  identification  of  air  target  A1  is 
hostile." 


( (FOE . I ARGE I . I  DENI  I F I  CHI  I  ON . RULE 
(IF  (FTARGET  IS  IN  CLASS  TARGETS) 

(THE  STATUS  OF  7TRRGET  IS  DETECTED) 

(THE  IFF. SIGNAL  OF  7IRRGET  IS  DIFFERENT) 

(THE  IDENTIFICHIIOH  OF  7TnRGET  IS  FOE))) 
(FRIEND.IARGET .IDENIIFICAIION.RULE 
(IF  (7THR0ET  IS  IN  CLASS  TARGETS) 

(THE  SIRIUS  OF  7THRGEI  IS  DEIECIED) 

(THE  IFF. SIGNAL  OF  7IARGEI  IS  SANE) 

(THE  IDENTIFICATION  OF  7IRRGET  IS  FRIEND)))) 


Figure  5-3.  TARGET.IDENTIFICATION.RULES  in  RULES.3 
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Figure  5-4  shows  the  TARGET.CLASSIFICATION.RULES  subclass 
rule  of  RULES.3.  This  subclass  rule  is  used  to  classify  the  category  of  target.  For 
example,  to  apply  the  AIR.TARGET.CLASSIFICATION.RULE  rule,  the 

following  conditions  must  be  true: 

•  Air  target  A1  is  in  class  targets,  and 

•  The  status  of  air  target  A1  is  detected,  and 

•  The  speed  of  air  target  A1  greater  than  100  kts,  and 

•  The  characteristic  of  air  target  A1  is  air, 

then  we  can  reach  the  conclusion  "The  classification  of  air  target  A1  is  air." 


((HlR.IflRGtl .CLHSSIF ICfll lOM.RULt 
(IF  (?TBRGei  IS  IN  CLASS  TflRGeTS) 

(THE  STRIUS  OF  7lnRGEI  IS  DETECTED) 

(LISP  (>  (IHE  SPEED  OF  ?inRGEI)  180)) 

(THE  CHBRHCTERISTIC  OF  7TRRGET  IS  BIB) 

THEN 

(THE  CLBSSIFICflT ION  OF  7TfiRGET  IS  flIR))) 
(SUBSURFACE .  I BRGET .CLBSSI F I  CRT  I  ON . RULE 
(IF  (7IHRGET  IS  IN  CLASS  TARGETS) 

(THE  STRIUS  OF  7TAR0EI  IS  DETECTED) 

(LISP  (<=  (THE  SP'^ED  OF  7TRRGEI)  50)) 

(THE  CHARACTERISTIC  OF  7IRRGEI  IS  SUBSURFACE) 
THEN 

(IHE  CLASSIFICATION  OF  7IBRGET  IS  SUBSURFACE))) 
( SURF  ACE . T  RRGE I . CL ASS  I F I  CAT  I  ON . RUL  E 
(IF  (7TARCEI  IS  IN  CLASS  TARGETS) 

(THE  SIRIUS  OF  7TARGEI  IS  DETECTED) 

(LISP  (<  (THE  SPEED  OF  7IBRGEI )  100>) 

(IHE  CHARACTERISTIC  OF  7IRRGET  IS  SURFACE) 

THEN 

(IHE  CLASSIFICATION  OF  7TRRGET  IS  SURFACE)))) 


Figure  5-4.  TARGET.CLASSIFICATION.RULES  in  RULES.3 
tj.  RULESA  in  Knowledge  Base 

Figure  5-5  shows  the  TRACKING.SENSOR.RULES  subclass  rule 
in  RULES.4.  This  subclass  rule  shows  what  kind  sensor  is  tracking  on  the 
target.  For  example,  to  apply  the  S/A.R  rule,  if  the  following  conditions  are 
true: 

•  Surface  ship  Radar  is  in  class  sensors,  and 

•  The  status  of  surface  ship  Radar  is  on,  and 

•  The  status  of  air  target  A1  is  detected,  and 
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•  The  relative  range  of  air  target  A1  less  than  or  equal  to  the  maximum 
detective  range  of  surface  ship  Radar,  and 

•  The  characteristic  of  surface  ship  Radar  is  air,  and 

•  DDGB  is  in  class  forces,  and 

•  The  characteristic  of  air  target  A1  is  air,  and 

•  The  sensor  of  DDGB  is  surface  ship  Radar, 

then  we  can  reach  the  conclusion  'The  tracking  sensor  of  DDGB  is  surface 
ship  Radar." 


((S/fl.R 

(IF  (7PLRTF0Rn  IS  IN  CLASS  FORCES) 

(7SENS0R  IS  IH  CLASS  SENSORS) 

(THE  STATUS  OF  7SENS0R  I S  ON ) 

(THE  STATUS  OF  7TRRGEr  IS  DETECTED) 

(LISP  (<=  (THE  RELATIVE. range  OF  7TRRGET)  (THE  hAK. DETECT  I UE .RANGE  OF  7SEHS0R))) 
(THE  CHARACTERISTIC  OF  7SENS0R  IS  AIR) 

(THE  CHARACTERISTIC  OF  7TARGET  IS  AIR) 

(THE  SENSOR  OF  7PLRTF0Rn  IS  7SENS0R) 

THEN 

(THE  TRACK  I  NO.  SENSOR  OF  7PLATF0Rf1  IS  7SEHS0R))) 

(S/S.R 

(IF  (7PLATF0Rn  IS  IN  CLASS  FORCES) 

(7SENS0R  IS  IN  CLASS  SENSORS) 

(THE  STATUS  OF  7SENS0R  IS  ON) 

(THE  STATUS  OF  7TARGET  IS  DETECTED) 

(LISP  (<s  (THE  RELATIVE. RANGE  OF  7TARGET)  (THE  NAM . DETECT  I UE .RANGE  OF  7SENS0R>)) 
(LISP  (<  0  (THE  RELATIVE. RANGE  OF  7TRRGET))) 

(THE  CHARACTERISTIC  OF  7SENS0R  IS  SURFACE) 

(THE  CHARACTERISTIC  OF  7TARGET  IS  SURFACE) 

(THE  SENSOR  OF  7PLRTF0Rn  IS  7SEHS0R) 

THEN 

(THE  TRACKINO.SENSOR  OF  7PLATF0RN  ?S  7SENS0R))) 

(S/U.R 

(IF  (?PLATF0Rn  IS  IN  CLASS  FORCES) 

(7SeNSOR  IS  IN  CLASS  SENSORS) 

(THE  STATUS  OF  7SENS0R  IS  ON) 

(THE  STATUS  OF  7TARGET  IS  DETECTED) 

(LISP  (<=  (THE  RELATIVE. range  OF  7TRRGET)  (THE  I1AK. DETECT  I VE. RANGE  OF  7SEMS0R))> 
(THE  CHARACTERISTIC  OF  7SENS0R  IS  SUBSURFACE) 

(THE  characteristic  OF  7fARGET  IS  SUBSURFACE) 

(THE  SENSOR  OF  7PLRTF0Rn  IS  7SEHS0R) 

THEN 

(THE  TRACKINO.SENSOR  OF  7PLBTF0RM  IS  7SENS0R)))) 


Figure  5-5.  TRACKING.SENSOR.RULES  in  RULES.4 


Figure  5-6  shows  the  WEAPON.SUGGESTION.RULES.l  subclass 
rule  in  RULES.4.  This  subclass  rule  is  used  to  generate  the  weapon  suggestion 
instructions.  The  suggested  on  board  weapons  are  to  be  assigned  to  the  targets. 

For  example,  to  apply  the  S/  A.W  rule,  if  the  following  conditions  are  true: 

•  Air  target  A1  is  in  class  targets,  and 

•  DDGB  is  in  class  forces,  and 

•  The  identification  of  air  target  A1  is  hostile,  and 
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(IF  (7TftRGET  IS  IN  CLRSS  TRRGCTS) 

(7PLRT FOR/1  IS  IN  CLRSS  FORCES) 

(THE  IDEHTIFICRTION  OF  7TRR0ET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TAR0ET  IS  flIR) 

(LISP  (<=  (THE  RELRTIUE.RRNGE  OF  7TRRGET)  (THE  NRK. FIRING. RRHOE  OF  7UERP0H))) 

(LISP  (>*  (THE  RELATIVE, RANGE  OF  7TRR0ET)  (THE  niH. FIRING. RANGE  OF  ?UEfiPON))) 

(LISP  (<=  (THE  RELATIVE. BERRINO  OF  TTRRGET  )  (THE  UP .Lini T .F I  RING .SECTOR  OF  7UEflP0N))) 
(LISP  (>s  (THE  RELATIVE. BEARING  OF  ?TRRO£y>  (THE  DOWN. LI NI T .FI RI NG . SECTOR  OF  7UEflP0N))  1 

(THE  CHARACTERISTIC  OF  7WERPON  IS  S^A) 

(THE  REFERENCES  OF  7PLRTF0Rft  IS  INTERESTED) 

(THE  UEAPOH  OF  7PLATFORN  IS  ?ueAPON) 

(THE  UEAPON. STATUS  OF  7UEAP0H  IS  AVAILABLE) 

(THE  RELATIVE. bearing  OF  7rRRGET  IS  7eEARING) 

(THE  RELATIVE. RANGE  OF  7TRRGET  IS  7RRNGE ) 

THEN 

(THE  BEARING. SUGGESTION  OF  7UEAP0N  IS  7GEARtHG) 

(THE  RANGE. SUGGEST  1  OH  OF  7UEAPON  IS  7RAHGE) 

(LISP  (PUT. VALUE  7UEAP0H  'WEAPON, ASS I  ON  'S/A)) 

(LISP  (PUT. VALUE  7UERP0H  'SUGGEST. TO  7rARGEr)) 

(LISP  (PUT. VALUE  7UERP0N  'WEAPON. STATUS  ' NOT .AVAILABLE ))) ) 

(S/S.U 

(IF  (7rRRG£T  IS  IN  CLASS  TARGETS) 

(7PLRTF0Rn  IS  IN  CLASS  FORCES) 

(THE  IDENTIFICATION  OF  7TARGET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TARGET  IS  SURFACE) 

(LISP  (<s  (THE  RELAT IVE.RRHGE  OF  7TRRGei  )  (THE  hRX. FIRING. RANGE  OF  7UEnP0N))) 

(LISP  (>s  (THE  RELAT I  VS. RANGE  OF  7TARGET)  (THE  hIN. FIRING. RANGE  OF  7UEAP0N))) 

(LISP  (<=  (THE  RELATIVE. BEARING  OF  7TARGET)  (THE  UP.Lini T . FI RI HO .SECTOR  OF  7UEAPON))) 
(LISP  (>s  (THE  RELATIVE. BEARING  OF  ?TAfiG£T)  (THE  DOWN. LINI T .FIRING. SECTOR  OF  7WEAP0H))  I 

(THE  CHARACTERISTIC  OF  7UEAPON  IS  S/S) 

(THE  REFERENCES  OF  7PLATF0RH  IS  INTERESTED) 

(THE  WEAPON  OF  7PLATF0Rf1  IS  7weRPOH) 

(THE  WEAPON. STATUS  OF  7UEAP0N  IS  AVAILABLE) 

(THE  RELATIVE, BEARING  OF  7TARGET  IS  ?eEAR|HG) 

(THE  relative. range  OF  7TARGET  IS  7RAHGE)  _  _ 

IHEH 

(THE  BEBRIHO. SUGGEST  ION  OF  7UERP0N  IS  7BEARIHO) 

(THE  range. SUGGEST  ION  OF  7UEAPQH  IS  7RANGe) 

(LISP  (PUT. VALUE  7UEAP0N  'WEAPON. ASSIGN  'S/S)) 

(LISP  (PUT. VALUE  7UeAP0N  'SUGGEST. TO  7TARGET)) 

(LISP  (PUT. VALUE  7UEAPOH  ' WEAPON . ST ATUS  'NOT .AVAILABLE )>) ) 

(S/U.w 

(IF  (7TARGET  IS  IN  CLASS  TARGETS) 

(?PLATFORri  IS  IN  CLASS  FORCES) 

(THE  IDENTIFICATION  OF  ?IAflGET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TARGET  IS  SUBSURFACE) 

(LISP  (<s  (THE  RELATIVE.RAHGE  OF  7IARGET)  (THE  NAH.FI RI NO .RANGE  OF  7UERP0N))) 

(LISP  ()s  (THE  RELATIVE.RAHGE  OF  7TARGET)  (THE  hlN. FIRING. RANGE  OF  7UERP0N))) 

(LISP  (<s  (THE  relative, SEARING  OF  7IARGET)  (THE  UP.LlNl T .F I RI NO . SECT  OR  OF  7WERP0H))) 
(LISP  (>s  (THE  RELATIVE. BEARING  OF  ?TARGei)  (THE  DOWN. LINI T . F I RI HO .SECTOR  OF  7UERPOH))  ! 

(THE  CHARACTERISTIC  OF  7WERP0N  IS  S/U) 

(THE  REFERENCES  OF  7PLATF0Rf1  IS  INTERESTED) 

(THE  WEAPON  OF  7PLATFORn  IS  7WEflP0H) 

(THE  WEAPON. STATUS  OF  7UERP0N  IS  AVAILABLE) 

(THE  relative. bearing  OF  7TARGET  IS  7SEARIN0) 

(THE  RELATIVE. RANGE  OF  7TRRGEr  IS  7RRNGE) 

THCN 

(THE  SERRIHO, SUGGESTION  OF  7UeAP0H  IS  rBEARlNG) 

(THE  RANGE, SUGGEST  ION  OF  7UEflP0N  IS  7RANGE) 

(LISP  (PUT .VALUE  7UERP0N  'WEAPON, ASSIGN  'S/U)) 

(LISP  (PUT. VALUE  7WEAP0N  'SUGGEST. TO  ?TflRGET)) 

(LISP  (PUT. VALUE  TWERPON  'WEAPON. STATUS  'NOT .AVRIIABLE) ) )) ) 


Figure  5-6.  Weapon  Suggestion  Rules  for  Single  Target  Appearing  in 

Different  Dimensions 


•  The  classification  of  air  target  A1  is  air,  and 

•  The  relative  range  of  air  target  A1  less  then  or  equal  to  the  maximum 
firing  range  of  SAM  (Surface  to  Air  Missile),  and 

•  The  relative  range  of  air  target  A1  greater  then  or  equal  to  the 
minimum  firing  range  of  SAM,  and 
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•  The  relative  bearing  of  air  target  A1  less  than  or  equal  to  the  up  limit 
firing  sector  of  SAM,  and 

•  The  relative  bearing  of  air  target  A1  greater  than  or  equal  to  the  down 
limit  firing  sector  of  SAM,  and 

•  The  characteristic  of  SAM  is  s/a,  and 

•  The  reference  of  DDGB  is  interested,  and 

•  The  weapon  of  DIXSB  is  SAM,  and 

•  The  weapon  status  of  SAM  is  available,  and 

•  The  relative  bearing  of  air  target  A1  is  X  degree  and 

•  The  relative  range  of  air  target  A1  is  Y  mile, 

then  we  can  reach  the  conclusion  "The  SAM  is  suggested  for  use  against  air 
target  Al." 

Figure  5-7  and  Figure  5-8  are  the 
WEAPON.SUGGESTION.RULES.2  subclass  rules.  Figure  5-9  is 
WEAPON. PRIORITY. RULES  subclass  rules.  Both  are  the  subclass  rules  of 
RULES.4. 

WEAPON.ASSIGNMENT.RULES.2  are  used  when  there  is  an 
occurrence  of  multiple  targets.  The  weapon  suggestions  are  based  on  the 
target  threat  classes  in  conjunction  with  the  weapon  priority  to  formulate 
optimal  weaponry  deployment  against  the  targets.  The 
WEAPON.PRIORTTY.RULES  are  designed  to  be  employed  when  the  relative 
range  of  the  target  is  less  than  the  efficient  minimum  firing  range  of  the 
assigned  weapon.  It  changed  so  as  to  maintain  defensive  integrity. 
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Ul  .KfcbLtCI 

(IF  (VTflRGET  IS  IH  CLASS  TARGETS) 

(7PLArF0Rf1  IS  IN  CLASS  FORCES) 

(THE  IDENTIFICATION  OF  7TRRGET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TARGET  IS  AIR) 

(LISP  (<=  (THE  RELATIOE. RANGE  OF  7TARGEI )  (THE  NAX. FIRING. RANGE  OF  TUCAPON))) 

(LISP  (>=  (THE  RELATIUE.RRHGE  OF  7TARGET)  (THE  NIN. FIRING. RANGE  OF  7UEAP0N))) 

(LISP  (<=  (THE  RELATIVE. BEARING  OF  7TARGET)  (THE  UP. LINIT .FIRING. SECTOR  OF  7UEAP0N))) 
(LISP  (>=  (THE  RELATIVE. BEARIMQ  OF  7TARGET  )  (THE  DOUN. LI ni T .F I  RING . SECTOR  OF  7UERPOH))  I 

) 

(THE  CHARACTERISTIC  OF  7UEAP0N  IS  S^A) 

(THE  REFERENCES  OF  7PLATF0RM  IS  INTERESTED) 

(THE  UEAPON  OF  7PLATF0Rri  IS  7UEAP0H) 

(THE  UEAPON.STATUS  OF  7UEAPON  IS  NOT .AVAILABLE) 

(LISP  (EQUAL  (THE  TOTAL .A . THREAT  OF  7TARGET)  (THE  WEAPON. PRIORI  TV  OF  7UERP0N))) 

(THE  RELATIve.SEARINO  OF  7TARGET  IS  78EARIH0> 

(THE  RELATIVE. RANGE  OF  7TARGET  IS  7RAHGE) 

(THE  WEAPON.ASSIGN  OF  7HEAP0N  IS  S/A) 

THEN 

(LISP  (PUT, VALUE  7UEAP0N  'BEAR I NO. SUGGEST  ION  78eARIH0)) 

(LISP  (PUT, VALUE  7UERP0H  ' RANGE .SUGGEST ION  7RRHGE)) 

(LISP  (PUT. VALUE  7WERP0H  ‘WEAPON. ASSIGN  'S^A)) 

(LISP  (PUT. VALUE  7WEAP0N  'SUGGEST. TO  7TRRGET)) 

(LISP  (PUT. VALUE  7UERP0N  'UEAPON.STATUS  'HOT .AVAILABLE ))) ) 

(S^U.U.REbLfcCf 

(IF  (7TARGET  IS  IN  CLASS  TARGETS) 

(7PLATF0Rn  IS  IN  CLASS  FORCES) 

(THE  IDENTIFICATION  OF  7TRRGET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TRRGET  16  SUBSURFACE) 

(LISP  (<=  (THE  RELATIVE. RANGE  OF  7TRRGET)  (THE  OAK. FI  RING. RANGE  OF  7UeAP0H))) 

(LISP  <>s  (THE  RELAT/Ve.PANGE  Of  7TARGET)  (THE  ttlN.Fl RI NO .RANGE  OF  7UERP0N))) 

(LISP  (<=  (THE  RELATIVE. BEARING  OF  7TRRC6T)  (THE  UP. LINIT .FIRING. SECTOR  OF  7UERP0N))) 
(LISP  (>=  (THE  RELATIVE. BEARING  OF  7TARGET)  (THE  DOWN. LIMIT .FIRING. SECTOR  OF  7WEAP0H))  I 

*  (THE  CHARACTERISTIC  OF  7WEAPOH  IS  S/U) 

(THE  REFERENCES  OF  7PLATFORri  IS  INTERESTED) 

(THE  WEAPON  OF  7PLRTF0RN  IS  7UERP0H) 

(THE  UEAPON.STATUS  OF  7UERP0H  IS  NOT .AVAILABLE ) 

(LISP  (EQUAL  (THE  TOTAL .U , THREAT  OF  7TARGE1)  (THE  WEAPON .PRl ORI TY  OF  7UEflP0H))> 

(THE  RELATIVE. BEARING  OF  7TARGET  IS  7BEARIHG) 

(THE  RELATIVE. RANGE  OF  7TRRGET  IS  7RRNGE) 

THEN 

(LISP  (PUT. value  7UERPON  'BEARING, SUGGEST  I ON  7BEARING>) 

(LISP  (PUT, value  ‘^WEAPON  'RANGE . SUGGEST  ION  ?RANG£>> 

(LISP  (PUT. value  7UEAPON  'WEAPON, ASSIGN  'S^U)) 

(LISP  (PUT.  value  ‘^WEAPON  'SUGGEST.  TO  7IARGET)) 

(LISP  (PUT, VALUE  7UERP0N  'WEAPON. STATUS  'NOT .AVAILABLE )))) ) 


Figure  5-7.  Weapon  Suggestion  Rules  for  Multiple  Air  and  Subsurface 

Targets 
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(S^S.Wi .RESLECr 

(IF  (7TRRGET  IS  IH  CLASS  TfiRGETS) 

(7PLflTF0Rn  IS  IN  CLRSS  FORCES) 

(THF  IDENTIFICRTION  OF  7TflRGET  IS  FOE) 

(THE  CLRSSIFICRTION  OF  7TRR0Er  IS  RIR) 

(LISP  (<=  (THE  RELRTIUE.RRHGE  OF  7TfiRGET)  (THE  ttRK. FIRING. RANGE  OF  7UEflP0N))) 

(LISP  (>=  (THE  RELATIVE. RANGE  OF  7IARGET)  (THE  NIN. FIRING. RANGE  OF  7UEflP0N))) 

(LISP  (<=  (THE  RELATIVE. BERRIHG  OF  7TAR0ET)  (THE  UP .Li MI T . F I RI HO . SECTOR  OF  7UERP0H))) 
(LISP  (>=  (THE  RELATIVE. BEARING  OF  7TflR0£T)  (THE  DOUN. LI ni T . FI RI NG . SECTOR  OF  7UEAP0H))  I 

) 

(THE  CHARACTERISTIC  OF  7UEAP0N  IS  S/A) 

(THE  REFERENCES  OF  7PLATF0RM  IS  INTERESTED) 

(THE  WEAPON  OF  7PLATF0Rn  IS  7WEAP0N) 

(THE  WEAPON. STATUS  OF  7UEAP0N  IS  HOT .AVAILABLE) 

(THE  RELATIVE. BEARING  OF  7TAR0ET  IS  76EARIND) 

(THE  RELATIVE. RANGE  OF  7TARGET  IS  7RANGE) 

(THE  WEAPON. ASSIGN  OF  7UEAPQH  IS  S/S) 

I  HEN 

(LISP  (PUT. VALUE  7UEAP0N  'BEARING. SUGGESTION  7eEARIN0)) 

(LISP  (PUT. VALUE  7WEAP0N  'RANGE. SUGGEST  I ON  7RRHGE)) 

(LISP  (PUT. VALUE  7UEAP0N  'WEAPON. ASSIGN  'S^A)) 

(LISP  (PUT. VALUE  7UEAPON  'SUGGEST. TO  7TAR6ET)) 

(LISP  (PUT. VALUE  '’WEAPON  'WEAPON. STATUS  'NOT .AVAILABLE ))) ) 

(S/S.U2.RESLECT 

(IF  (7TRRGET  IS  IN  CLRSS  TARGETS) 

(7PLATFORf1  IS  IH  CLASS  FORCES) 

(THE  IDENTIFICATION  OF  7TRRGET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TRRGET  IS  AIR) 

(LISP  (<=  (THE  RELATIVE. RANGE  OF  7TARGET)  (THE  nRN.FlRI NO. RANGE  OF  7WERP0N))) 

(LISP  (>=  (THE  RELATIVE. RANGE  OF  7TARGET)  (THE  ttlH. FIRING. RANGE  OF  7UEAPON))) 

(LISP  (<s  (THE  RELATIVE. BEARING  OF  7TARGET)  (THE  UP .LI HI T .FI RI NO. SECTOR  OF  7UEAP0N))) 
(LISP  <>s  (THE  RELATIVE.8EARIN0  OF  ?rARO£?)  (THE  DOWN. L INI T .FI RING. SECTOR  OF  7WEAPON)) 

) 

I  (THE  CHARACTERISTIC  OF  7HERP0N  IS  S^A) 

I  (THE  REFERENCES  OF  ?PLRTFnRf1  IS  INTERESTED) 

!  (THE  WEAPON  OF  7PLATF0RM  IS  7UEAP0N) 

I  (THE  WEAPON. STATUS  OF  7UEAPOH  IS  NOT  .AVAILABLE) 

(LISP  (EQUAL  (THE  TOTAL . S. THREAT  OF  7TARGET)  (THE  WEAPON. PRIORITY  OF  7UERP0N))) 

(THE  RELATIVE. BEARING  OF  7TARGeT  IS  78EARING) 

(THE  RELATIVE. RANGE  OF  7TRRGET  IS  7RAN6E) 

(THE  WEAPON, ASSIGN  OF  ?U£nPOH  IS  S/S) 

THEN 

(LISP  (PUT. VALUE  7UERP0N  'BEARING. SUGGEST  I ON  78EARING)) 

(LISP  (PUT, VALUE  7UEAPON  ' RANGE .SUGGEST  ION  7RAHGE)) 

(LISP  (PUT. VALUE  7UEAPON  'WEAPON. ASSIGN  'S^A)) 

(LISP  (PUT, VALUE  7UEAP0H  'SUGGEST. TO  7TARGET)) 

(LISP  (PUT, VALUE  7UERP0N  'WEAPON, STATUS  'NOT .AVAILABLE ))) ) 

(S/S.U3,RtbLECT  --  • 

(IF  (7TARGET  IS  IH  CLASS  TARGETS) 

('’PLATFORM  IS  IN  CLASS  FORCES) 

(THE  IDENTIFICATION  OF  7TRRGET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TARGET  IS  SURFACE) 

(LISP  (<=  (THE  RELRT IVE.RRNGE  OF  7TflR0ET  )  (THE  MAH. FIRING. RANGE  OF  7UERP0N))) 

(LISP  (>=  (THE  RELATIVE. RANGE  OF  7TARGET  )  (THE  Ml H.F I RI HG . RANGE  OF  ’’WEAPON))) 

(LISP  (<=  (THE  RELATIVE. BEARING  OF  7TfiR6ET )  (THE  UP.LI MI T . F I RI NG . SECT  OR  OF  7UEAPON))) 
(LISP  (>s  (THE  RELATIVE. BEARING  OF  7TRR6ET )  (THE  DOWN . LI  MI T . F I RI NO . SECTOR  OF  7UEAPON))  I 

(THE  CHARACTERISTIC  OF  7UERP0N  IS  S^S ) 

(THE  REFERENCES  OF  7PLATF0RM  IS  INTERESTED) 

(THE  WEAPON  OF  7PLRTF0RM  IS  7UEAP0N) 

(THE  WEAPON, STATUS  OF  7UERP0N  IS  HOT .AVAILABLE) 

(LISP  (EQUAL  (THE  TOT AL . S . THREAT  OF  7TARGET )  (THE  WEAPON . PRI ORI TY  OF  7UERPON))) 

(The  relative. BEARING  OF  7TRRGET  IS  7BERRIN0) 

(THE  RELATIVE. RANGE  OF  7TRRGET  IS  7RRMGE ) 

(THE  WEAPON, ASSIGN  OF  7UEAP0N  IS  S/S) 

THEN 

(LISP  (PUT.VA  UE  7WERP0H  *  BEAR I  MG . SUGGEST  I  OH  7BEARING)) 

(LISP  (PUT. VALUE  7UERP0N  ' RANGE .SUGGEST  I  ON  7RRNGE ) ) 

(LISP  (PUT. VALUE  7UEAP0N  'WEAPON. ASSIGN  '$/$)) 

(LISP  (PUT. VALUE  7UERP0N  'SUGGEST. TO  '’TARGET)) 

(LISP  (PUT. VALUE  7WEAP0N  'WEAPON. STATUS  'NOT  .AVAI LRBLE ) ) ) ) 


Figure  5-8.  Weapon  Suggestion  Rules  for  Multiple  Surface  Targets 
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US/ft.WEflPON.PRiORITY .EXCHRNGE.R 
(IF  (TTflROET  IS  IH  CLRSS  TARGETS) 

(THE  IDENTIFICRTION  OF  7TRRGET  IS  FOE) 

(THE  CUftSSlFICATIQH  OF  7TflRGEr  IS  AIR) 

('^UERPQH  IS  IH  CLASS  UEAPONS) 

(THE  CHARACTERISTIC  OF  7UERP0H  IS  S/A) 

(LISP  (<  (THE  RELATIVE. RANGE  OF  ?TRRGEr)  (THE  ttlN. FIRING. RANGE  OF  7UEAPON))) 
THEN 

(LISP  (PUT. VALUE  'SAn  'UEAPOH . PRl ORI TV  'AIRE)) 

(LISP  (PUT. VALUE  *76ttN  'WEAPON. PRIORI  TV  'AIRI)) 

(LISP  (ADD. VALUE  '76nh  *  WEAPON. PRI ORl TY  'SUFI)))) 

( S/S . WEAPON .PRIORITY. EXCHANGE . R 
(IF  (7TRRGET  IS  IH  CLASS  TARGETS) 

(THE  IDENTIFICATION  OF  7TARGET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TRRGET  IS  SURFACE) 

(?WEAPaN  IS  IH  CLASS  WEAPONS) 

(THE  CHARACTERISTIC  OF  7UEAP0H  IS  S/S) 

(LISP  (<  (THE  RELATIVE. RANGE  OF  7TARGET)  (THE  NIN .F I R1 NO .RANGE  OF  7WERP0N))) 
THEN 

(LISP  (PUT. VALUE  'SSfl  'WEAPON. PRIORITY  'SUF2)) 

(LISP  (PUT. VALUE  * 76Nn  *  WEAPON .PRIORI lY  'SUFI)) 

(LISP  (ADD. VALUE  •76f1f1  'WEAPON.  PRIORI  TY  'A|RI))>> 

(S/U . WEAPON .PRIORITY. EXCHANGE .R 
(IF  (7TRRGET  IS  IN  CLASS  TARGETS) 

(THE  IDENTIFICATION  OF  7TARGEI  IS  FOE) 

(THE  CLASSIFICATION  OF  7TRRGET  IS  SUBSURFACE) 

(7WERPON  IS  IN  CLASS  WEAPONS) 

(TNE  CHRRACiERISl 1C  OF  7HEAP0N  IS  S/U) 

(LISP  (<  (THE  RELATIVE, RANGE  OF  7TARQET )  (THE  NIN.F I R1 HO . RANGE  OF  7UERPON))) 
THEN 

(LISP  (PUT. VALUE  'ASROC  ' WEAPON . PRI ORI TY  'SUBS)) 

(LISP  (PUT. VALUE  'ASU.TORPEOO-l  'WEAPON. PRIORI TY  'SUBI)) 

(LISP  (PUT. VALUE  ‘ ASU . TORPEOO-2  'WEAPON. PRIOR! TY  'SUBI))))) 


Figure  5-9.  WEAPON.PRIORITY.RULES  in  RULES.4 


c.  RULES.5  in  Knowledge  Base 

There  are  five  subclass  rules  in  RULES.5  (see  Figure  5-1).  The 
major  function  of  RULES.5  is  to  calculate  the  threat  class  of  the  target  and 
assign  a  threat  class  to  the  corresponding  target.  This  rule  is  utilized  in  those 
situations  where  multiple  targets  appear,  because  of  the  obvious  need  in  such 
a  context  to  use  the  appropriate  weapon  against  the  respective  targets.  The 
following  example  shows  how  the  SORT.A.RULES  rule  in  RULES.5  works  in 
a  given  condition.  The  SORT.A.RULES  in  RULES.5  is  shown  in  Figure  5-10.  If 
the  following  conditions  are  true: 

•  Air  target  A1  is  in  class  targets,  and 

•  The  identification  of  air  target  A1  is  hostile,  and 
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•  The  classification  of  air  target  A1  is  air,  and 

•  Sort  (from  large  to  small)  threat.a.value  of  unit  class  targets  and  store 
into  variable  AW,  and 

•  The  slot  threat.l  of  unit  air  target  A1  equal  to  the  first  vaiuv;  of  variable 
AW, 

then  we  can  reach  the  conclusion  "The  threat  class  of  air  target  A1  is  AIRl." 


((SOftl  .fil 

(IF  (7TflRGET  IS  IN  CLASS  TARGETS) 

(THE  IDENTIFICATION  OF  7TARGET  IS  FOG) 

(THE  CLASSIFICATION  OF  7TRRGEr  IS  AIR) 

(LISP  (NOT  (EQUAL  (QET.URLUES  ‘TARGETS  ‘THREAT.A.VALUE)  NIL))) 
(LISP  (SETF  AU  (GET. VALUES  ‘TARGETS  ' THREAT .A. VALUE) ) ) 

(LISP  (SORT  AU  «' > ) ) 

(LISP  (EQUAL  (GET. VALUE  7TARGET  ‘THREAT. I )  (FIRST  AU))) 

THEN 

(LISP  (PUT. VALUE  7TRRGET  * T 01 AL .A. THREAT  ‘AlRI)))) 

(SORT ,A2 

(IF  (7TRRGET  IS  IN  CLASS  TARGETS) 

(THE  IDENTIFICATION  OF  7TARGET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TARGET  IS  AIR) 

(LISP  (NOT  (EQUAL  (GET. VALUES  ‘TARGETS  ‘THREAT.A.VALUE)  NIL))) 
(LISP  (SETF  AU  (GET, VALUES  ‘TARGETS  ‘THREAT.A.VALUE))) 

(LISP  (SORT  AU  ll‘>)) 

(LISP  (EQUAL  (GET. VALUE  7TARGET  ‘THREAT.!)  (SECOND  AU))) 

THEN 

(LISP  (PUT. VALUE  7TARGET  ‘ TOTAL .A. THREAT  'RIR2)))) 

(SORT .A3 

(IF  (7TARGET  IS  IN  CLASS  TARGETS) 

(THE  IDENTIFICATION  OF  7TRRGET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TRRGET  IS  AIR) 

(LISP  (NOT  (EQUAL  (GET. VALUES  ‘TARGETS  ‘THREAT.A.VALUE)  NIL))) 
(LISP  (SETF  AU  (GET, VALUES  ‘TARGETS  ‘THREAT.A.VALUE))) 

(LISP  (SORT  AU  B‘>)) 

(LISP  (EQUAL  (GET. VALUE  7TRRGET  ‘THREAT. I)  (THIRD  AU))) 

THEN 

(LISP  (PUT. VALUE  7TARGET  ' TOT AL .A. THREAT  ‘RIR3)))) 

(SORT ,A4 

(IF  (7TARGET  IS  IH  CLASS  TARGETS) 

(THE  IDENTIFICATION  OF  7TARGEr  IS  FOE) 

(THE  CLASSIFICATION  OF  7TARGET  IS  AIR) 

(LISP  (NOT  (EQUAL  (GET. VALUES  ‘TARGETS  ‘THREAT. A. VALUE)  NIL))) 
(LISP  (SETF  AU  (GET, VALUES  'TARGETS  ‘THREAT.A.VALUE))) 

(LISP  (SORT  AU  «'>)) 

(LISP  (EQUAL  (GET. VALUE  7TARGET  ‘THREAT. I)  (FOURTH  AU))) 

THEN 

(LISP  (PUT. VALUE  7TARGET  ‘ TOTAL . A . THREAT  ‘BIR4)))) 

(SORT .AS 

(IF  (7TARGET  IS  IN  CLASS  TARGETS) 

(THE  IDENTIFICRTIOH  OF  7TRRGET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TRRGET  IS  AIR) 

(LISP  (NOT  (EQUAL  (GET. VALUES  ‘TARGETS  'THREAT.A.VALUE)  NIL))) 
(LISP  (SETF  AU  (GET. VALUES  ‘TARGETS  ' THREAT .A. VALUE) ) ) 

(LISP  (SORT  AU  *'>)) 

(LISP  (EQUAL  (GET. VALUE  7TBRGET  'THREAT. 1)  (FIFTH  AU))) 

THEN 

(LISP  (PUT. VALUE  7TRRGET  ‘ TOTAL .A . THREAT  'AIRS))))) 


Figure  5-10.  SORT.A.RULES  in  RULES.5 


It  is  important  that  we  sort  different  types  of  targets  by  different 
rules.  SORT.A.RULES  are  for  air  targets,  SORT.U.RULES  are  for  subsurface 
targets  (see  Figure  5-11)  and  SORT.S.RULES  are  for  surface  targets  (see  Figure 
5-12).  In  order  to  efficiently  match  the  available  weaponry  in  the  platform 


DDGB  (Guided  Missile  Destroyer)  we  use  three  different  sort  rules  in  the 
performance  of  the  sorting  function.  From  Chapter  IV  we  have  five  weapons 
available  for  air  targets,  five  weapons  available  for  surface  targets  and  three 
weapons  available  for  subsurface  targets.  Therefore,  we  only  assign  threat 
class  for  air  targets  from  AIRl  ~  AIRS,  surface  targets  from  SUFI  ~  SUF5  and 
subsurface  targets  from  SUBl  ~  SUB3.  The  threat  value  is  calculated  by  the 
following  equation: 

threat  value  =  (target's  speed)  +  (2500 /(target’s  relative  range  +  0.01)) 

+  ((target's  relative  bearing) /1 000) 


(SORI .U1 

(IF  (?tflR0Er  IS  IN  CLASS  IfiRGEIS) 

(THE  IDENTIFICATION  OF  7IARGET  IS  FOE) 

(THE  classification  OF  7IRRGEI  IS  SUBSURFACE) 

(LISP  (HOI  (EQUAL  (GEI.UALUES  'TARGETS  ' THREAT .U .URLUE )  HIL))) 
(LISP  (SETF  UU  (GET.URLUES  'TARGETS  ' THREAT .U. VALUE )) ) 

(LISP  (SORT  UU  »■>)) 

(LISP  (EOURL  (GET. URLUE  7IRRGET  'THREAT. 3)  (FIRST  UU))) 

THEN 

(LISP  (PUT. URLUE  7TBRGEI  ' TOTAL .U. THREAT  'SUBI)))) 

(SORT .UE 

(IF  (7rRRGET  IS  IN  CLASS  TARGETS) 

(THE  IDEHIIFICATION  OF  7TRRGET  IS  FOE) 

(THE  CLASSIFICAIION  OF  7IRRGEI  IS  SUBSURFACE) 

(LISP  (NOT  (EQUAL  (GEI.UALUES  'TARGETS  ' IHREHI .U. URLUE)  HIL))) 
(LISP  (SETF  UU  (GEI.UALUES  'TARGETS  ' THREAT .U. VALUE )) ) 

(LISP  (SORT  UU  S'))) 

(LISP  (EQUAL  (GET. URLUE  7TRRGEI  'THREAT. 3)  (SECOND  UU))) 

THEN 

(LISP  (PUT. VALUE  7TRRGET  ' TOTAL .U. THREAT  'SUB2)))) 

(S0RT.U3 

(IF  (?TnRGET  IS  IN  CLASS  TARGETS) 

(THE  IDENTIFICATION  OF  7IRRGEI  IS  FOE) 

(THE  CLASSIFICATION  OF  7TRRGET  IS  SUBSURFACE) 

(LISP  (MOT  (EQUAL  (GEI.UALUES  'TARGETS  ' THREAT .U. URLUE )  NIL))) 
(LISP  (SEIF  UU  (GEI.UALUES  'TARGETS  ' THREAT .U. URLUE )) ) 

(LISP  (SORT  UU  «'>)) 

(LISP  (EQUAL  (GET. URLUE  7TRRGET  'THREAT. 3)  (THIRD  UU))) 

THEN 

(LISP  (PUT. VALUE  7IRRGET  ' TOTAL .U .THREAT  'SUB3))))) 


Figure  5-11.  SORT.U.RULES  in  RULES.5 


This  is  a  general  equation  based  on  the  target's  data  and  we 
assume  it  can  satisfy  our  operational  considerations  (in  fact,  for  different 
operational  considerations  the  threat  value  equation  must  be  different).  Users 
can  change  the  constant  on  each  term.  For  example,  if  speed  is  an  especially 
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salient  factor,  then  it  can  be  assigned  a  greater  relative  value  than  range  in  the 
equation.  The  bearing  term  is  used  to  guarantee  that  no  more  than  one  object 
will  be  assigned  location  at  the  same  point  and  time.  We  will  discuss  how  the 
threat  value  been  calculated  in  weapon  suggestion  system  in  section  D  (see  p. 
54). 


((SORT. SI 

(IF  (7TnRGET  IS  IH  CLASS  TARGETS) 

(THE  IDENTIFICATION  OF  7TRRGET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TRRGET  IS  SURFACE) 

(LISP  (NOT  (EQUAL  (GET.UflLUES  'TARGETS  ' THREAT .S. VALUE )  NIL))) 
(LISP  (SETF  SU  (GET. VALUES  'TARGETS  ' THREAT .S. VALUE) ) ) 

(LISP  (SORT  SU  »'>)) 

(LISP  (EQUAL  (GET. VALUE  7TARGET  'THREAT. 2)  (FIRST  SU))) 

THEN 

(LISP  (PUT. VALUE  7TARGET  ' TOTAL . S. THREAT  'SUFI)))) 

(SORT.Sa 

(IF  (7TRR0ET  IS  IN  CLASS  TARGETS) 

(THE  IDENTIFICATION  OF  7TRRQET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TARGET  IS  SURFACE) 

(LISP  (NOT  (EQUAL  (GET. VALUES  'TARGETS  ' THREAT .S. VALUE)  NIL))) 
(LISP  (SETF  SU  (GET. VALUES  'TARGETS  ' THREAT .S. VALUE )) ) 

(LISP  (SORT  SU  «'>)) 

(LISP  (EQUAL  (OET. VALUE  7TARGET  'THREAT. 2)  (SECOND  SU))) 

THEN 

(LISP  (PUT, VALUE  7TARGET  ' TOTAL .S. THREAT  'SUF2)))) 

(SORT .S3 

(IF  (7TRRGET  IS  IN  CLASS  TARGETS) 

(THE  IDENTIFICATION  OF  7TRRGET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TARGET  IS  SURFACE) 

(LISP  (NOT  (EQUAL  (GET. VALUES  'TARGETS  ' THREAT .S. VALUE )  NIL))) 
(LISP  (SETF  SU  (GET. VALUES  'TARGETS  'THREAT .S. VALUE )) ) 

(LISP  (SORT  SU  «'>)) 

(LISP  (EQUAL  (GET. VALUE  7TARGET  'THREAT. 2)  (THIRD  SU))) 

THEN 

(LISP  (PUT. VALUE  7TRRGET  ' TOT AL . S . THREAT  'SUF3)))) 

(S0RT.S4 

(IF  <7TARG£T  IS  IN  CLASS  TARGETS) 

(THE  IDENTIFICATION  OF  7TRRGET  IS  FOE) 

(THE  CLASSIFICATION  OF  ?TARGeT  IS  SURFACE) 

(LISP  (NOT  (EQUAL  (GET. VALUES  'TARGETS  ' THREAT .S. VALUE )  NIL))) 
(LISP  (SETF  SU  (GET. VALUES  'TARGETS  ' THREAT VALUE )) ) 

(LISP  (SORT  SU  ll'>)) 

(LISP  (EQUAL  (GET. VALUE  7TRRGET  'THREAT. 2)  (FOURTH  SU))) 

THEN 

(LISP  (PUT. VALUE  7TRRGET  ' T OTAL . S . THREAT  'SUF4)))) 

(SORT .S5 

(IF  (7TARGET  IS  IN  CLASS  TARGETS) 

(THE  IDENTIFICATION  OF  'TARGET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TRRGeT  IS  SURFACE) 

(LISP  (NOT  (EQUAL  (GET. VALUES  'TARGETS  'THREAT .S. VALUE)  NIL))) 
(LISP  (SETF  SU  (GET. VALUES  'TARGETS  ' THREAT .S. VALUE )) ) 

(LISP  (SORT  SU  fl'>)) 

(LISP  (EQUAL  (GET. VALUE  7TRRGET  'THREAT. 2)  (FIFTH  SU))) 

THEN 

(LISP  (PUT, VALUE  7TflRGET  'TOTAL, S. THREAT  'SUF5))))) 


% 


Figure  5-12,  SORT.S.RULES  in  RULES.5 


3.  User  Interface 

KEE  provides  graphical  tools,  called  KEEpictures,  for  interface  design. 
They  simplify  data  input  and  generate  output  display  that  allows  the  user  to 
interact  with  the  system  easily.  Figure  5-13  shows  the  user  interface  of  the 
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WSS.  Each  block  in  Figure  5-13  is  called  a  unit.  The  units  for  data  input  (in 
the  bottom  of  Figure  5-13)  can  be  accessed  by  mouse  or  keyboard.  The 
reminder  units  serve  as  output  display  (i.e.  the  suggest  instructions  for  a 
specified  case).  Generally,  we  can  input  the  target  data  by  clicking  on  the  data 
input  unit  and  then  select  the  data  from  the  submenu,  or  type  in  the  data 
from  the  keyboard  if  there  are  no  submenu  appear.  The  functions  of  each  of 
the  data  input  and  output  display  units  are  described  below: 


Rnowtctf'io  UifCf 


ASW 

KB** 


Trarklnx-S^nitr 


1  r  A  c a  1 114.&  ••  MR 


nm’t  BtsUngSuggntUn_ Isim'i  BMtln*5u*n*au» 


TracKvtt.Tarctt 


188 

129  .  240 
60  0^“***^  308 
8/  ^360 


188 

120  240 

60  300 

0  /  \  360 


awjgfttT 

Atw.Ttrifflvri  VftrlititSaicrtiUn 


1201*8  2^g 


|A8w.T<irH*t*r«  i Aiw.Torfrtv-r* S 


I rA»t0*i  Ch* r« cttfliMc.O 


Unknown 


Tr«c)i*A.Tatsci: 


180 

120  ,  240 
60  300 

0  360 


I  Afg  Trpetcrfpt  Wi/>rfow 


Scndtieteagt  valuei  NIL 


B««rlnf.SflXAeitl«n 


180 

120  240 


48mm»ri  HtngfJ 


KIiKLI 


40}nm-t'«  Suxx«8t 


Unknown 


Aiw.T«ret4«-l*i  B*«rlnK.8vKK^ttton 


120  240 


A(WkTQrM4t>2*<  R 


UnknoMt)  ||  Unknoun  ||  Unknoun  l|  Unknown  11  Unknown  I  Unknown 


Tcrcctf'i  Namt 


Iff  Jtgnil.Own 


Unknown 


A«w.Torpf4»"l'«B 


4Pmm*2’«  OfArlntSuctriUftn 


180 

120  ,  240 
60  ^,>V‘J*«<<^300 
0/  \360 


POmm't'f  Ranxe)  40inm*2’t  Sutttil 

E 


nknoun  11  Unknoun 


Atroc'i  B0*rlnR-$«ctritl*n 


180 

120  ,  248 
60  300 


Clwt’i  B«trlnx.$u»E0itlen 
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Figure  5-13.  User  Interface  of  WSS 
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tL  Data  Input  Units 

•  Forces's  Select. Reference  unit:  to  engage  the  selected  platform  in  the 
knowledge  base.  For  the  purposes  of  this  thesis  we  have  only  used  the 
DIX5B  in  the  knowledge  base. 

•  Target’s  Name  unit:  to  designate  a  name  to  the  target  appearing  on  the 
sensor.  The  name  can  be  any  characters  or  symbols. 

•  Weng's  Order  unit:  to  start  our  simulation  for  a  given  data  input. 

•  Li’s  Reset  unit:  to  reset  the  weapon  suggestion  system  by  clicking  it. 

•  Li’s  IP. Reset  unit:  to  reset  the  data  input  unit  by  clicking  it. 

•  Targets’s  Characteristic.Own  unit:  the  characteristic  of  the  target  (i.e  air, 
surface  or  subsurface).  In  fact,  we  can  deduce  the  target  characteristic 
from  the  sensor  input.  For  example,  if  the  target  is  detected  by  Sonar 
then  we  can  assume  the  target  characteristic  should  be  subsurface.  V  the 
target  is  detected  by  s/a  Radar  then  the  target  characteristic  should  be  air, 
etc. 

•  Targets’s  Iff. Signal. Own  unit:  the  IFF  signal  identification  of  the  target.  If 
it  is  a  hostile  target  the  IFF  signal  should  be  different,  otherwise  the  IFF 
signal  will  be  same.  Both  this  and  Targets’s  Characteristic.Own  units, 
can  be  accessed  by  first  clicking  on  it  then  selecting  the  input  data  from 
the  submenu. 

•  Targets’s  Relative.Range.Own  unit:  the  range  (in  miles)  between  the 
ship  and  target. 

•  Targets’s  Speed.Own  unit;  the  speed  (in  knots)  of  the  target. 

•  Targets’s  Relative.Bearing.Own  unit:  the  bearing  between  our  own 
ships  heading  and  the  target  (the  unit  is  degree).  This  unit  and  Targets’s 
Relative.Range.Own  as  well  as  Targets’s  Speed.Own  units  can  be 
accessed  by  dicing  on  the  horizontal  bar  or  the  dial  at  any  scale. 

•  Surface.Ship.Radar’s  Status  unit:  to  set  the  surface  ship  Radar  (on  or 
ofO. 

•  Surf  ace. Ship. Esm’s  Status  unit:  to  set  the  surface  ship  ESM  (on  or  ofO- 

•  Surf ace.Ship. Sonar’s  Status  unit:  to  set  the  surface  ship  Sonar  (on  or 
ofO-  The  three  status  units  can  be  accessed  by  clicking  it  on.  If  the  user 
wishes  to  activate  the  surface  ship  Radar  they  can  use  the  mouse  to  dick 
the  'on'  part  of  the  screen  to  the  corresponding  units.  The  device  is  'on' 
when  the  background  screen  has  become  white. 
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•  Targets’s  Destroyed  unit:  to  input  the  name  of  a  target  that  has  been 
destroyed.  This  allows  the  target  name  to  be  deleted  from  the  knowledge 
base. 

•  Li’s  Destroyed  unit:  an  actuator  to  start  the  delete  procedure  of  the 
destroyed  target. 

b.  Output  Display  Units 

•  Sam’s  Bearing.Suggestion  unit:  the  display  of  bearing  suggestion  of 
SAM. 

•  Sam’s  Range. Suggestion  unit:  the  display  of  range  suggestion  of  SAM. 

•  Sam’s  Suggest. To  unit:  the  display  of  the  target  to  which  SAM  is 
suggested. 

•  Ssm’s  Bearing.Suggestion  unit:  the  display  of  bearing  suggestion  of 
SSM. 

•  Ssm’s  Range. Suggestion  unit:  the  display  of  range  suggestion  of  SSM. 

•  Ssm’s  Suggest. To  unit:  the  display  of  the  target  to  which  SSM  is 
suggested. 

•  76mm’s  Bearing.Suggestion  unit:  the  display  of  bearing  suggestion  of 
76mm. 

•  76mm’s  Range. Suggestion  unit:  the  display  of  range  suggestion  of 
76mm. 

•  76mm’s  Suggest. To  unit:  the  display  of  the  target  to  which  76mm  is 
suggested. 

•  40mm-l’s  Bearing.Suggestion  unit:  the  display  of  bearing  suggestion  of 
40mm-l. 

•  40mm-l’s  Range. Suggestion  unit:  the  display  of  range  suggestion  of 
40mm-l. 

•  40mm-l’s  Suggest.To  unit:  the  display  of  the  target  to  which  40mm-l  is 
suggested. 

•  40mm-2’s  Bearing.Suggestion  unit:  the  display  of  bearing  suggestion  of 
40mm-2. 

•  40mm-2’s  Range. Suggestion  unit:  the  display  of  range  suggestion  of 
40mm-2. 

•  40mm-2’s  Suggest.To  unit:  the  display  of  the  target  to  which  40nun-2  is 
suggested. 
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•  Ciws's  Bearing.Suggestion  unit:  the  display  of  bearing  suggestion  of 
CIWS. 

•  Ciws^s  Range.Suggestion  unit:  the  display  of  range  suggestion  of  CIWS. 

•  Ciws*s  Suggest. To  unit:  the  display  of  the  target  to  which  CIWS  is 
suggested. 

•  Asw.Torpedo-Vs  Bearing.Suggestion  unit:  the  display  of  bearing 
suggestion  of  ASW/Torpedo-1. 

•  Asw.Torpedo-Vs  Range. Suggestion  unit:  the  display  of  range  suggestion 
of  ASW/Torpedo-1. 

•  Asw.Torpedo-Vs  Suggest.To  unit:  the  display  of  the  target  to  which 
ASW/Torpedo-1  is  suggested. 

•  Asw.Torpedo-2's  Bearing.Suggestion  unit:  the  display  of  bearing 
suggestion  of  ASW/Torpedo-2. 

•  Asw.Torpedo-2's  Range. Suggestion  unit:  the  display  of  range  suggestion 
of  ASW/ Torpedo-2. 

•  Asw.Torpedo-2's  Suggest.To  unit:  the  display  of  the  target  to  which 
ASW/Torpedo-2  is  suggested. 

•  AsroVs  Bearing.Suggestion  unit:  the  display  of  bearing  suggestion  of 
ASROC. 

•  AsroVs  Range.Suggestion  unit:  the  displav  of  range  suggestion  of 
ASROC. 

•  Asroc's  Suggest.To  unit:  the  display  of  the  target  to  which  ASROC  is 
suggested. 

C  SIMULATIONS 

In  this  section  we  set  up  several  test  cases  to  demonstrate  our  weapon 
suggestion  system.  The  targets  will  be  added  into  the  system  one  by  one  and 
the  system  will  suggest  the  best  response  to  each  situation. 

1.  Case  1:  Three  Hostile  Targets  Appearing  in  Different  Dimensions 
For  this  situation  the  system  suggestion  is  shown  in  Figure  5-14.  In 
this  case  our  sensors  detect  three  unknown  targets,  one  each  from  air,  surface, 
and  subsurface,  which  are  approaching  the  ships  DDGB.  The  targets  are 
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analyzed  by  sensors  and  the  IFF  device  on  board,  as  shown  in  Table  5-1,  and 
the  results  are  then  fed  to  the  WSS. 


SURrACE^HIf^ONAIK  VSION  SURrACZ^IItP.ESM  SUtrACZ^IIIP.RAOAR 


IttrlinJiiiitHllM  llm'i  IttrliiiJaitMUiii 


Figure  5-14.  Simulation  Display  of  Case  1 


TABLE  5-1.  TARGET  PARAMETERS  OF  CASE  1 


target 

characteristic 


different 


different 


different 


relative 

relative 

target 

threat 

range 

bearing 

speed 

(mile) 

(degree) 

(knots) 

class 

20.29 

330 

750 

airl 

5.22 

091 

48 

sufl 

6.1 

246 

25 

subl 

surface 

subsurface 


50 


We  used  the  results,  calculated  by  threat  value  equation  (see  Chapter  IV 
p.  49),  to  decide  the  threat  class  for  each  target.  The  threat  classes  are  listed  in  the  table. 
Based  on  target  and  weapon  parameters  listed  in  Table  4-2,  WSS  display  is  shown  Figure 
5-14.  SAM  is  suggested  for  use  against  Al,  since  it  is  the  only  weapon  available  and  able 
to  reach  an  air  target.  For  surface  target  SI,  because  it  is  within  range  of  both  76nim  and 
SSM  both  weapons  are  suggested.  For  subsurface  target  U1  only  the  ASROC  can  be  used. 

2.  Case  2:  Multiple  Hostile  Targets  Appearing  in  Air  and  Surface 

In  this  case  we  have  three  air  (A1-A3)  and  three  surface  (S1~S3) 
targets.  The  target  parameters  are  listed  in  Table  5-2.  The  simulation  results 
are  displayed  in  Figure  5-15.  The  threat  values  have  been  calculated  by  the 
threat  value  equation.  Based  on  the  threat  values  for  each  targets  we  list  the 
threat  class  in  Table  5-2.  The  weapon  suggestion  for  each  target  is  described 
below: 

•  SAM  was  suggested  for  use  against  A2. 

•  76mm,  40mm-2,  and  CIWS  were  suggested  for  use  against  A3. 

•  SSM  was  suggested  for  use  against  S3. 

•  40mm-l  was  suggested  for  use  against  S2. 


TABLE  5-2,  TARGET  PARAMETERS  OF  CASE  2 


target 

characteristic 

relative 

range 

(mile) 

relative 

bearing 

(degree) 

target 

speed 

(knots) 

threat 

class 

Al 

air 

different 

10 

030 

750 

aLr3 

A2 

air 

different 

5.2 

097 

750 

air2 

A3 

air 

different 

1.45 

285 

750 

airl 

SI 

surface 

different 

40 

015 

50 

suf3 

S2 

surface 

different 

2.02 

106 

35 

sufl 

S3 

surface 

different 

5.8 

180 

35 

suf2 

51 


Since  the  system  was  defined  to  assign  a  deployment  priority  to  air 
targets,  the  76mm  was  used  to  counterstrike  A3.  On  the  other  hand,  because 
A1  and  SI  do  not  satisfy  the  premises  (e.g.  they  might  be  out  of  the  maximum 
firing  range  of  weapons  or  no  weapons  are  available)  for  the  rules, 
consequently  there  are  no  optimal  weapons  that  can  be  suggested. 


Figure  5-15.  Simulation  Display  of  Case  2 


3.  Case  3:  Multiple  Hostile  Targets  Appearing  in  Three  Dimensions 

In  this  case  four  air  (A1~A4),  four  surface  (S1~S4),  and  three 
subsurface  (U1~U3)  targets  were  input  into  the  WSS.  The  target  parameters 


are  listed  in  Table  5-3.  The  simulation  results  are  displayed  in  Figure  5-16.  The 
threat  class  for  each  of  the  targets  are  listed  in  Table  5-3  also.  The  weapon 

deployment  of  this  case  is  described  below: 

•  SAM  was  suggested  for  use  against  A3- 

•  76mm,  40mm-l,  and  CIWS  were  suggested  for  use  against  A4. 

•  SSM  was  suggested  for  use  against  S4. 

•  40mm-2  was  suggested  for  use  against  S3. 

•  ASROC  and  ASW/ Torpedo-1  were  suggested  for  use  against  U3. 

•  ASW /Torpedo-2  was  suggested  for  use  against  U2. 

For  targets  Al,  A2,  SI,  S2,  and  U1  no  weapons  can  be  suggested,  since 
they  do  not  satisfy  the  premises  for  the  rules  (e.g.  they  might  be  a  friend  or  no 
weapons  available  for  use  against  them). 


TABLE  5-3.  TARGET  PARAMETERS  OF  CASE  3 


target 

characteristic 

relative 

range 

(mile) 

relative 

bearing 

(degree) 

target 

speed 

(Imots) 

threat 

class 

Al 

air 

different 

10 

030 

750 

air3 

A2 

air 

same 

5 

180 

750 

no  1 

A3 

air 

different 

4 

285 

750 

aii2 

A4 

air 

different 

1.5 

090 

700 

airl 

SI 

surface 

different 

40 

015 

50 

suf3 

S2 

surface 

same 

2.5 

255 

35 

no  1 

S3 

surface 

different 

1.5 

255 

50 

sufl  1 

S4 

surface 

different 

6 

180 

35 

suf2 

U1 

subsurface 

different 

5 

090 

25 

sub3 

U2 

subsurface 

different 

2.5 

285 

40 

subl 

U3 

subsurface 

different 

4 

105 

25 

sub2  1 
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D.  SOME  IMPLEMENTATION  PROBLEMS 

1.  How  to  Decide  the  Threat  Class  for  Targets? 

In  section  b  we  gave  the  threat  value  equation  which  is  stored  in  the 
slot  CALCULATE.A,  CALCULATE.S  and  CALCULATE.U  for  air,  surface,  and 
subsurface  targets,  respectively.  The  CALCULATE. A. RULE, 
CALCULATE.S.RULE  and  CALCULATE.U.RULE  in  RULES.5  are  used  to 
collect  the  target  data  and  send  them  to  the  corresponding  slot  used  in  the 
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calculation  of  the  threat  value  for  the  target.  The  threat  value  is  then  stored 
in  the  slot  THREAT.  1  (for  air  target),  THREAT.2  (for  surface  target)  or 
THREAT.3  (for  subsurface  target).  Finally,  all  air  target  threat  values  will  be 
collected  into  slot  TOTAL.A. VALUE.  Then,  the  values  in  TOTAL.A. VALUE 
slot  will  be  sorted  from  large  to  small.  The  largest  value  in  the  slot  means  the 
corresponding  target  has  the  highest  threat  class.  Similarly,  the  smallest  value 
in  TOTAL. A. VALUE  slot  means  the  corresponding  target  has  the  lowest 
threat  class.  For  surface  and  subsurface  targets  the  threat  values  will  be 
collected  into  slot  TOTAL.S.VALUE  or  TOTAL.U.VALUE.  Using  the  same 
procedures  we  can  generate  and  designate  threat  class  to  each  corresponding 
targets.  The  CALCULATE. RULES  and  ADD.CALCULATE.RULES  subclass 
rules  are  shown  in  Figure  5-17  and  Figure  5-18. 


(CHi.CULni6.^.i^UL£ 

(If  (?rflftceT  ($  IN  CLASS  targcts) 

(TmC  loeHtlFICATION  Of  ?TPR0£T  IS  FOE) 

(THE  CLRSSIFICRTIOH  OF  ’TARGET  IS  AIR) 

(LISP  (NOT  (EQUAL  (OET. VALUES  ’TARGET  ‘RELAT I VE.RAnOE)  NIL))) 
(LISP  (HOT  (EQUAL  (GET. VALUES  ’T«’PGEf  'SPEED)  NIL))) 

(LISP  (HOT  (EQUAL  (GET. VALUES  ’ThROEt  'RELAT I V£ .0EARIHO)  NIL))) 
TMEH 

(LISP  (UHITHSO  ’TARGET  'CALCULATE. A)))) 

(CALCULATE. S. RULE 
(IF  (’TARGET  IS  IN  CLASS  TARGETS) 

(THE  IflEHTlFlCATlOH  OF  ’TARGET  IS  FOE) 

(THE  CLASSIFICATION  OF  ’TARGET  IS  SURFACE) 

(LISP  (HOT  (EQUAL  (GET. VALUES  ’TARGET  ' RELAT I VE .RANGE )  NIL))) 
(LISP  (HOT  (EQUAL  (GET. VALUES  ’TARGET  'SPEED)  NIL))) 

(LISP  (HOT  (EQUAL  (GET. VALUES  ’TARGET  'RELAT I VE .BEARING )  NIL))) 
THEN 

(LISP  (UNlTnSG  ’TARGET  'CALCULATE .S  )))  ) 

(CALCULATE. U. RULE 
(IF  (’TARGET  IS  IN  CLASS  TARGETS) 

(THE  TCEHTJf JCATION  OF  ’TARGET  IS  FOE) 

(THE  CLASSIFICATION  OF  ’TARGET  IS  SUBSURFACE) 

(LISP  (HOT  (EQUAL  (GET. VALUES  ’TARGET  'RELATIVE. RANGE)  NIL))) 
(LISP  (NOT  (EQUAL  (OET. VALUES  ’TARGET  'SPEED)  NIL))) 

(LISP  (NOT  (EQUAL  (GET. VALUES  ’TARGET  ' RELAT IVE .BEARING)  MIL))) 
THEN 

(LISP  (UNITHSO  ’TARGET  'CALCULAT  E  .U)  )  )  )  ) _  _ 


Figure  5-17.  CALCULATE.RULES  in  RULES.5 


2.  How  to  Create  and  Delete  a  Target  from  the  Knowledge  Base? 

All  the  targets  have  been  added  into  the  knowledge  base  by  means  of 
the  user  interface  (i.e.  Targets's  Name  unit).  From  the  Targets's  Name  unit 
we  can  input  the  target's  name.  Then,  the  RULES.  1  rule  will  create  the  name 
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as  a  instance  which  will  be  linked  as  a  "child"  of  the  class  TARGETS  in  the 
knowledge  base.  Similarly,  we  use  the  same  method  to  delete  the  destroyed 
targets  from  the  knowledge  base. 


((ADD. B. RULE 

(IF  (7TRRGET  IS  IN  CLASS  TARGETS) 

(The  identification  of  ?TnRGET  IS  FOE) 

(The  CLASSIFICATION  OF  7TRR0ET  IS  AIR) 

(THE  THREAT. I  OF  ?TARG£r  IS  7UALUE) 

THEN 

(LISP  (ADD. VALUE  'TARGETS  'THREAT .A. VALUE  7UALUE)))) 
(ADD. S. RULE 

(IF  (7TRR6ET  IS  IN  CLASS  TARGETS) 

(THE  IDENTIFICATION  OF  7TARGET  IS  FOE) 

(THE  CLASSIFICATION  OF  7TARGET  IS  SURFACE) 

(THE  THREAT. 2  OF  7TARGET  IS  7UALUE) 

THEN 

(LISP  (ADD. VALUE  'TARGETS  *  THREAT . S. VALUE  7UALUE)))) 
(ADD. U. RULE 

(IF  (7TARQET  IS  IH  CLASS  TARGETS) 

(THE  IDENTIFICATION  OF  ?TAfiG£T  IS  FOE) 

(THE  CLASSIFICATION  OF  7TRRGET  IS  SUBSURFACE) 

(THE  THREAT. 3  OF  7TflRGET  IS  7UALUE) 

THEN 

(LISP  (ADD. value  'TARGETS  ' THREAT , U. VALUE  ?UflLU£))))) 


Figure  5-18.  ADD.CALCULATE.RULES  in  RULES.5 
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VI.  CONCXUSIONS 


A.  SUMMARY 

This  thesis  focuses  on  using  an  expert  system  approach  in  designing  an 
intelligent  weapon  suggestion  system  capable  of  assisting  the  Weaponry 
Department  Head  in  making  efficient  and  accurate  decisions  in  critical  war  at 
sea  scenarios. 

In  Chapter  I  we  described  the  objectives  of  building  such  a  system,  as  well 
as  the  attendant  problems.  We  discussed  some  general  background  and 
related  work  in  Chapter  II  and  III.  In  Chapter  IV  we  explained  the  basic 
concepts  pertaining  to  the  structure,  design,  and  limitations  of  a  WSS.  In 
Chapter  V  we  explored  the  developmental  environment,  knowledge  base, 
and  some  special  problems  in  the  implementation  and  treatment  of  the 
system.  The  software  implementation  and  simulation  results  were  also 
presented  in  Chapter  V  as  well. 

B.  FUTURE  WORK 

We,  and  many  others,  have  shown  that  the  tactical  knowledge,  reasoning, 
and  decision  making  process  within  combat  situations  can  be  modelled  by 
production  rules  and  expert  systems  technology.  However,  it  is  beyond  the 
scope  of  our  design  prototype  to  approach  a  fully  integrated  paradigm  that 
would  have  included  a  more  detailed  analysis  of  the  crucial  interactions  of 
the  system  with  the  combat  system  and  its  weaponry,  which  holds  the 
promise  of  forming  the  basis  of  an  automatic  weapon  assignment  system  a 
more  powerful  than  the  existing  prototypes.  In  fact,  the  unstated  goal  of  our 
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design  work  on  the  WSS  is  to  progress  and  evolve  towards  a  fully  integrated 
automatic  weapon  assignment  system. 

In  keeping  with  the  aspiration  to  develop  an  operational  automatic 
weapon  assignment  system  is  the  future,  the  following  considerations 
necessitate  solutions: 

•  How  to  establish  the  performance  and  data  link  between  the  WSS  and 
its  periphery? 

•  How  to  design  and  implement  an  automatic  weapons  system  on  board 
that  achieves  full  utilization  of  the  expert  system? 

•  How  to  join  and  wholly  integrate  the  considerations  of  tactical 
operations  into  the  system? 

•  How  to  establish  all  the  connections  and  linkages  of  electronic  warfare 
into  mechanical  functions  of  the  system? 
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APPENDIX.  THE  WSS  FLOW  CHART 


Figure  A-1.  Target  Detected  Flow  Chart 


59 


Figure  A-2.  Get  Target  Data  Flow  Chart 
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Figure  A-3.  Target  Identification  Flow  Chart 


multiple  hostile 
targets  appe^  in  one 
dimension  ? 


threat  of  single 
hostile  target  is 
air#l  or 
surface  #1  or 
subsurface  #1 


Figure  A-4.  Decide  Niunber  of  Targets  Flow  Chart 
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Figure  A-5.  Target  Destroyed  Flow  Chart 
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Figure  A-6.  Sort  Air  Target  Threat  Qass  Flow  Chart 
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Figure  A-7.  Sort  Air  Target  Threat  Class  Flow  Chart  (continued) 
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surface 
threat#  1 


first  max. 
threat  value 


second  max. 
threat  value 


third  max. 
threat  value 


fourth  max. 
threat  value 


fifth 

threat  value 


any  air  or  surface 
or  subsurface 
targets  need  to  assign 
threat  value  ? 


block  D  end 


Figure  A-8.  Sort  Surface  Target  Threat  Class  Floiv  Chart 
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Figure  A-9.  Sort  Subsxirface  Target  Threat  Qass  Flow  Chart 
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Figxire  A-10.  Against  Air  Target  Weapon  Suggestion  Flow  Chart 
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E-2 


Figure  A-11.  Against  Air  Target  Weapon  Suggestion  Flow  Chart  (continued) 
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SSM  available,  surface  target 
appear^S  NM  ^  target  relative  range 
NM,  0  ^  target  relative  beanng 
<  360,  target  t&eat  =  surface 
threat#!  or #2  or #3? 


76mni  available,  surface 
target  appear,  no  air  target  satis^ 
76mni  assignment  condition,  0.1  NM  ^ 
target  relauve  raime  <  8NM,  0  <  target 
relative  bearing  s  360,  target  threat  = 
surface  threat  #2  or  #  1  or  #3  ? 


n 


40nim-l  available,  surface 
target  appear,  no  air  target  satisfy 
40mm-l  assignment  condition,  O.Of  NM 
^  target  reliitive  rai^e  <  3  NM,  60  <  target 
relative  bearing  s  120,  target  threat  =  ^ 
surface  th^t  #3  or  #  1  or  #2  ? 


E-3 


Figtire  A-12.  Against  Surface  Target  Weapon  Suggestion  Flow  Chart 
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more  surface  targets 
need  to  check  ? 


E  -  surface^^^ 


more  subsurface 
targets  need  to  check  ? 


-  subsurface_^^ 


n 

block  E  end 


Figtire  A-13.  Against  Surface  Target  Weapon  Suggestion  Flow  Chart 

(continued) 


Figure  A-14.  Against  Subsurface  Target  Weapon  Suggestion  Flow  Chart 
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Figure  A-15.  Against  Subsurface  Target  Weapon  Suggestion  Flow  Chart 

(continued) 
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